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

Darin Fisher darin at chromium.org
Mon Apr 16 13:52:45 PDT 2012

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.


More information about the whatwg mailing list