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

[Darin Fisher]

On Thu, Mar 29, 2012 at 1:10 AM, Darin Fisher <darin at chromium.org> 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.
>
> -Darin
>


Also, there is a downside to the current convention of custom drawing modal
dialogs.  Web pages that mash-up content from varied sources would need to
have some convention for queuing up dialog requests.  Ideally, modal
dialogs should be shown in FIFO order rather than all at the same time.
 This seems like a tricky problem.  It seems like something the platform
could help with.  I believe the <dialog> proposal helps here.  I think
non-blocking alert, confirm and prompt helps in a similar vein.

-Darin




>
>
>>
>> I should add that this could be partly for path-dependent reasons, and
>> that if other technologies had been available, authors might not have
>> resorted to in-page modality with overlays. But I think the key missing
>> enabled was not asynchrony but rather the ability to fully control the UI,
>> layout and available commands of the modal experience.
>>
>> >
>> > alert() is mostly only used by either by sites with a low-quality user
>> experience, or as as non-production debugging aid. In both cases, authors
>> who care about the user experience will use <dialog> or a JS-implemented
>> "lightbox" style dialog. And authors who do not care about user experience,
>> or who are doing a quick debugging hack in non-production code, will use
>> old-fashioned blocking alert/confirm/prompt. Thus, I am not sure there is
>> really a meaningful audience for the non-blocking editions of these calls.
>> >
>> > Regards,
>> > Maciej
>> >
>> >
>> >
>> >
>> >
>>
>>
>