Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
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.
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@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 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.
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com 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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@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 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.
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Apr 16, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
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
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Thu, Mar 29, 2012 at 1:10 AM, Darin Fisher da...@chromium.org wrote:
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.
-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
Re: [whatwg] Proposal for non-modal versions of modal prompts
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
Re: [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 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
Re: [whatwg] Proposal for non-modal versions of modal prompts
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 20, 2012, at 6:04 PM, Boris Zbarsky wrote:
On 3/20/12 6:50 PM, Adam Barth wrote:
I'm not suredialog addresses the same use cases as alert() and
confirm() becausedialog 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
Re: [whatwg] Proposal for non-modal versions of modal prompts
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.
Adam
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger joc...@chromium.orgwrote: 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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On 3/20/12 6:50 PM, Adam Barth wrote:
I'm not suredialog addresses the same use cases as alert() and
confirm() becausedialog 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
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Tue, Mar 20, 2012 at 4:05 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger joc...@chromium.org 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
[whatwg] Proposal for non-modal versions of modal prompts
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
Re: [whatwg] Proposal for non-modal versions of modal prompts
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. `._.-(,_..'--(,_..'`-.;.'
