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

[Maciej Stachowiak]

On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote:

> 
> 
> 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.

The APIs as they currently exist are unable to provide an experience that is consistent with Mac OS X or iOS HI design. Modal alerts are rarely used in general, and when they are used, the buttons need to have labels that conform to the action rather than generic labels like "OK". I feel that the original design of alert(), confirm() and prompt() is very Windows-centric, and really Windows-circa-late-90s-centric. 

You could enhance the API to make these dialogs sufficiently more customizable. But then I am even more skeptical of the value over <dialog>.


> 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.

I think there's almost 0 times that it is correct to pop up an OK/Cancel dialog. If you incorporate customizing the button labels, I don't think <dialog> is materially more complicated.

Regards,
Maciej