Proposal for non-modal versions of modal prompts

[Jochen Eisinger-3]

Hey,

I'd like to put forward a proposal for extending the modal prompts
(alert/confirm/prompt) with an optional callback parameter. If the optional
callback parameter is present, the javascript execution would resume
immediately. The callback will be invoked when the dialog that doesn't need
to be browser modal now, is closed.

I wouldn't add such a callback to showModalDialog, as I think sites can use
e.g. window.open instead.

I've written up the proposal here: http://wiki.whatwg.org/wiki/Modal_prompts

The motivation for this is that in a tabbed browser, modal dialogs are
potentially disrupting the work flow of the user as they can't interact
with any other web site as long as the modal dialog is displayed.

Current browsers are having problems with the modal prompts:

Chromium for example doesn't display a window created by showModalDialog in
a modal way: http://crbug.com/16045

WebKit and Firefox don't suppress events while a modal dialog is running:
https://bugs.webkit.org/show_bug.cgi?id=78240 and
https://bugzilla.mozilla.org/show_bug.cgi?id=360872

Firefox displays modal prompts as tab-modal. However, it's possible to
execute JavaScript in a tab that should be blocked by a modal prompt:
https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from
separate tabs can block each other:
https://bugzilla.mozilla.org/show_bug.cgi?id=727801

Feedback on this proposal would be highly appreciated!

best
-jochen

[Ian Hickson]

On Mon, 19 Mar 2012, Jochen Eisinger wrote:

>
> I'd like to put forward a proposal for extending the modal prompts
> (alert/confirm/prompt) with an optional callback parameter. If the
> optional callback parameter is present, the javascript execution would
> resume immediately. The callback will be invoked when the dialog that
> doesn't need to be browser modal now, is closed.
>
> I wouldn't add such a callback to showModalDialog, as I think sites can
> use e.g. window.open instead.
>
> I've written up the proposal here:
> http://wiki.whatwg.org/wiki/Modal_prompts
>
> The motivation for this is that in a tabbed browser, modal dialogs are
> potentially disrupting the work flow of the user as they can't interact
> with any other web site as long as the modal dialog is displayed.
>
> Current browsers are having problems with the modal prompts:
>
> Chromium for example doesn't display a window created by showModalDialog
> in a modal way: http://crbug.com/16045
>
> WebKit and Firefox don't suppress events while a modal dialog is
> running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=360872
>
> Firefox displays modal prompts as tab-modal. However, it's possible to
> execute JavaScript in a tab that should be blocked by a modal prompt:
> https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from
> separate tabs can block each other:
> https://bugzilla.mozilla.org/show_bug.cgi?id=727801
>
> Feedback on this proposal would be highly appreciated!

Moving forward, I think the <dialog> element that we'll soon be adding is
probably a better direction to go in.

http://wiki.whatwg.org/wiki/Dialogs#Proposal

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Adam Barth-5]

On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson <ian@...> wrote:

> On Mon, 19 Mar 2012, Jochen Eisinger wrote:
>> I'd like to put forward a proposal for extending the modal prompts
>> (alert/confirm/prompt) with an optional callback parameter. If the
>> optional callback parameter is present, the javascript execution would
>> resume immediately. The callback will be invoked when the dialog that
>> doesn't need to be browser modal now, is closed.
>>
>> I wouldn't add such a callback to showModalDialog, as I think sites can
>> use e.g. window.open instead.
>>
>> I've written up the proposal here:
>> http://wiki.whatwg.org/wiki/Modal_prompts
>>
>> The motivation for this is that in a tabbed browser, modal dialogs are
>> potentially disrupting the work flow of the user as they can't interact
>> with any other web site as long as the modal dialog is displayed.
>>
>> Current browsers are having problems with the modal prompts:
>>
>> Chromium for example doesn't display a window created by showModalDialog
>> in a modal way: http://crbug.com/16045
>>
>> WebKit and Firefox don't suppress events while a modal dialog is
>> running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=360872
>>
>> Firefox displays modal prompts as tab-modal. However, it's possible to
>> execute JavaScript in a tab that should be blocked by a modal prompt:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from
>> separate tabs can block each other:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=727801
>>
>> Feedback on this proposal would be highly appreciated!
>
> Moving forward, I think the <dialog> element that we'll soon be adding is
> probably a better direction to go in.
>
> http://wiki.whatwg.org/wiki/Dialogs#Proposal

I'm not sure <dialog> addresses the same use cases as alert() and
confirm() because <dialog> is significantly more complicated.

== Non-modal confirm() ==

<script>
[...]
confirm("Are you sure you want to order the widget?", function(result) {
  if (result)
    sendOrder();
  else
    cancelOrder();
});
</script>

== <dialog> ==

<dialog id="orderConfirm">
Are you sure you want to order the widget?
<button onclick="document.getElementById('orderConfirm').close(true);">Ok</button>
<button onclick="document.getElementById('orderConfirm').close(false);">Cancel</button>
</dialog>
<script>
[...]
var dialog = document.getElementById('orderConfirm');
dialog.addEventListener('close', function() {
    if (dialog.returnValue == "true")
        sendOrder();
    else
        cancelOrder();
}, false);
dialog.showModal();
</script>

Even after all that, you get a less functional experience in some
respects.  For example, on Mac OS X, the Cancel button should be to
the left of the Ok button whereas on Windows they should be ordered as
in my example (i.e., with Ok to the left of Cancel).  I'm sure there's
some way to elaborate the sample code further to fix that bug, but I
think you get the point.

Adam

[Glenn Maynard]

On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger <jochen@...>wrote:

> I'd like to put forward a proposal for extending the modal prompts
> (alert/confirm/prompt) with an optional callback parameter. If the optional
> callback parameter is present, the javascript execution would resume
> immediately. The callback will be invoked when the dialog that doesn't need
> to be browser modal now, is closed.
>

I'm not sure this accomplishes anything.  It won't discourage people from
using the blocking dialog calls, because generally the entire reason people
use them is because the blocking is convenient.  People who don't need that
are likely to just use any old dialog overlay script that they can style to
match their page.

--
Glenn Maynard

[Boris Zbarsky]

On 3/20/12 6:50 PM, Adam Barth wrote:
> I'm not sure<dialog>  addresses the same use cases as alert() and
> confirm() because<dialog>  is significantly more complicated.

But also allows for much better UX...

> <dialog id="orderConfirm">
> Are you sure you want to order the widget?
> <button onclick="document.getElementById('orderConfirm').close(true);">Ok</button>
> <button onclick="document.getElementById('orderConfirm').close(false);">Cancel</button>

Those should be "Yes" and "No" respectively, according to every single
HIG I've seen.  Something that's not possible with confirm(), unfortunately.

Perhaps confirm() should take (optional) labels for the two buttons?

> Even after all that, you get a less functional experience in some
> respects.  For example, on Mac OS X, the Cancel button should be to
> the left of the Ok button whereas on Windows they should be ordered as
> in my example (i.e., with Ok to the left of Cancel).

Yep, this is a drawback for <dialog>....

-Boris

[Darin Fisher-3]

On Tue, Mar 20, 2012 at 4:05 PM, Glenn Maynard <glenn@...> wrote:

> On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger <jochen@...
> >wrote:
>
> > I'd like to put forward a proposal for extending the modal prompts
> > (alert/confirm/prompt) with an optional callback parameter. If the
> optional
> > callback parameter is present, the javascript execution would resume
> > immediately. The callback will be invoked when the dialog that doesn't
> need
> > to be browser modal now, is closed.
> >
>
> I'm not sure this accomplishes anything.  It won't discourage people from
> using the blocking dialog calls, because generally the entire reason people
> use them is because the blocking is convenient.  People who don't need that
> are likely to just use any old dialog overlay script that they can style to
> match their page.
>
>

While it would be nice to completely discourage use of blocking alert()
calls,
I don't think that is really the goal here.  The goal is to provide a super
simple
non-blocking set of dialog calls.  The alternative requires a fair bit of
code to
construct an overlay, etc.

-Darin

[Edward O'Connor-2]

Hi Darin,

You wrote:

> The alternative requires a fair bit of code to construct an overlay,
> etc.

Part of the idea of <dialog> is that the UA takes care of the (otherwise
painful) overlay setup etc. for you.


Ted

[Maciej Stachowiak]

On Mar 20, 2012, at 3:50 PM, Adam Barth wrote:

> On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson <ian@...> wrote:
>> On Mon, 19 Mar 2012, Jochen Eisinger wrote:
>>> I'd like to put forward a proposal for extending the modal prompts
>>> (alert/confirm/prompt) with an optional callback parameter. If the
>>> optional callback parameter is present, the javascript execution would
>>> resume immediately. The callback will be invoked when the dialog that
>>> doesn't need to be browser modal now, is closed.
>>>
>>> I wouldn't add such a callback to showModalDialog, as I think sites can
>>> use e.g. window.open instead.
>>>
>>> I've written up the proposal here:
>>> http://wiki.whatwg.org/wiki/Modal_prompts
>>>
>>> The motivation for this is that in a tabbed browser, modal dialogs are
>>> potentially disrupting the work flow of the user as they can't interact
>>> with any other web site as long as the modal dialog is displayed.
>>>
>>> Current browsers are having problems with the modal prompts:
>>>
>>> Chromium for example doesn't display a window created by showModalDialog
>>> in a modal way: http://crbug.com/16045
>>>
>>> WebKit and Firefox don't suppress events while a modal dialog is
>>> running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=360872
>>>
>>> Firefox displays modal prompts as tab-modal. However, it's possible to
>>> execute JavaScript in a tab that should be blocked by a modal prompt:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from
>>> separate tabs can block each other:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=727801
>>>
>>> Feedback on this proposal would be highly appreciated!
>>
>> Moving forward, I think the <dialog> element that we'll soon be adding is
>> probably a better direction to go in.
>>
>> http://wiki.whatwg.org/wiki/Dialogs#Proposal
>
> I'm not sure <dialog> addresses the same use cases as alert() and
> confirm() because <dialog> is significantly more complicated.
>
> == Non-modal confirm() ==
>
> <script>
> [...]
> confirm("Are you sure you want to order the widget?", function(result) {
>  if (result)
>    sendOrder();
>  else
>    cancelOrder();
> });
> </script>
>
> == <dialog> ==
>
> <dialog id="orderConfirm">
> Are you sure you want to order the widget?
> <button onclick="document.getElementById('orderConfirm').close(true);">Ok</button>
> <button onclick="document.getElementById('orderConfirm').close(false);">Cancel</button>
> </dialog>
> <script>
> [...]
> var dialog = document.getElementById('orderConfirm');
> dialog.addEventListener('close', function() {
>    if (dialog.returnValue == "true")
>        sendOrder();
>    else
>        cancelOrder();
> }, false);
> dialog.showModal();
> </script>
>
> Even after all that, you get a less functional experience in some
> respects.  For example, on Mac OS X, the Cancel button should be to
> the left of the Ok button whereas on Windows they should be ordered as
> in my example (i.e., with Ok to the left of Cancel).  I'm sure there's
> some way to elaborate the sample code further to fix that bug, but I
> think you get the point.

<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

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

[Maciej Stachowiak]

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

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

[Maciej Stachowiak]

On Mar 20, 2012, at 6:04 PM, Boris Zbarsky wrote:

> On 3/20/12 6:50 PM, Adam Barth wrote:
>> I'm not sure<dialog>  addresses the same use cases as alert() and
>> confirm() because<dialog>  is significantly more complicated.
>
> But also allows for much better UX...
>
>> <dialog id="orderConfirm">
>> Are you sure you want to order the widget?
>> <button onclick="document.getElementById('orderConfirm').close(true);">Ok</button>
>> <button onclick="document.getElementById('orderConfirm').close(false);">Cancel</button>
>
> Those should be "Yes" and "No" respectively, according to every single HIG I've seen.  Something that's not possible with confirm(), unfortunately.

Mac OS X HIG recommends that the active option should be labeled with a meaningful verb or verb phrase, not just something generic like "OK" or "Yes". So the proper labels would be "Order" and "Cancel" in this example.

reddit's login overlay, for example, actually meets the spirit of this requirement by having "create account", "login" and "close this window" as the available commands, though the layout is webby and consistent with the web app itself, rather than consistent with Mac UI conventions.

Regards,
Maciej

[Darin Fisher-3]

On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <mjs@...> 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

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

[Darin Fisher-3]

On Thu, Mar 29, 2012 at 1:10 AM, Darin Fisher <darin@...> wrote:

>
>
> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <mjs@...> 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
>> >
>> >
>> >
>> >
>> >
>>
>>
>

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

[Darin Fisher-3]

On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <mjs@...> wrote:

>
> On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
>
>
>
> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <mjs@...> 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.

Regards,
-Darin

[Tab Atkins Jr.]

On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher <darin@...> wrote:

> On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <mjs@...> 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

[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@...> wrote:
>
> On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
>
>>
>>
>> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <mjs@...> 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

[Darin Fisher-3]

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

> On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher <darin@...> wrote:
> > On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <mjs@...>
> 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