[whatwg] Proposal for non-modal versions of modal prompts
Jochen Eisinger
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
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
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
> 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
> 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
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
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 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
>
> 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
Darin Fisher
>
>
> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <m...@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.
>
> -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.