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

[Maciej Stachowiak]

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

Regards,
Maciej