On Mar 20, 2012, at 3:50 PM, Adam Barth wrote: > On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson <i...@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
