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

[Darin Fisher]

On Mon, Apr 16, 2012 at 2:03 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher <darin at chromium.org> wrote:
> > On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
> >> 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.
>
> I think you'll have a hard time finding people who prefer that. ^_^
>
> > 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.
>
> Hixie provided (in another thread) an example of the code required for
> <dialog> that was feature-equivalent to popping a prompt.  The
> difference is minimal.
>
> ~TJ
>


Oh, indeed he did.  Using <form> and <input> inside a <dialog> to create
simple dialogs is a nice idea.  I suppose the UA stylesheet could have some
extra rules to make that have a decent default rendering.  Hmm...

I'm starting to care a bit less about async{Alert,Confirm,Prompt}.
 Although,
it still bugs me that the path of least resistance for simple dialogs
will remain
good old thread-blocking modal alert/confirm/prompt :-(

-Darin