[whatwg] Proposal for non-modal versions of modal prompts

[Darin Fisher]

On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
>
>
>
> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
>>
>> >
>> > <dialog> will give a better user experience than even a non-modal
>> version of window.confirm() or window.alert(). Dialogs that are fully
>> in-page
>>
>> Oops, got cut off here. What I meant to say is something like "dialogs
>> that are fully in-page are the emerging standard for high-quality
>> page-modal prompting".
>>
>
> Non-blocking window.{alert,confirm,prompt} would most likely be rendered
> by UAs as in-page overlays / tab-scoped dialogs.  This is what we would do
> in Chrome, and it seems like others would do the same given the prevalence
> of the standard window.{alert,confirm,prompt} being implemented in a
> tab-scoped manner already by some browsers (albeit with bugs).
>
> I think people use alert, confirm and prompt in part because they are so
> easy to use.  People who choose window.{alert,confirm,prompt} probably
> don't care about loss of customization or else they would roll their own
> dialogs.
>
> Why not provide less sucky versions of those common dialogs?
>
> Benefit:  Less code for simple dialogs.
> Con:  Another web platform API to standardize.
>
>
> Con: Encourages poor HI design (since these stock dialogs should almost
> never be used).
>
> That being said, I find in-page UI less objectionable than a pop-up alert,
> but in that case I'm not sure it makes sense to overload the existing API.
> It would be better to make new methods so feature testing is possible. Even
> given all that, I'm not confident of the value add over <dialog>.
>
>
It seems like "poor HI design" is rather subjective.  Some might prefer the
OS-native look-and-feel of these simple dialogs.

Good point about feature testing.  I'd be OK with
async{Alert,Confirm,Prompt} or whatever name variant we prefer.

You don't see much value in the simplicity of having these methods be
provided by the platform?  It seems like <dialog> requires much more code
to setup.

Regards,
-Darin