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

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

> On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson <ian at hixie.ch> 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

Received on Wednesday, 21 March 2012 19:54:34 UTC