對話框與提示框（原: [whatwg] Dialogs and prompts）

HTML 規範最近加上了 <dialog> 相關的東西，有興趣的人可以看看相關討論：

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/thread.html#35314


-------- Original Message --------
Subject: [whatwg] Dialogs and prompts
Date: Wed, 11 Apr 2012 23:26:00 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: whatwg@whatwg.org


I just added a bunch of things relating to creating dialogs, popup
windows, inspectors, marking sections of applications as inert, and
related features to make it easier to build Web applications in HTML:

 - <dialog>: an element to mark up windows.

 - <dialog>.show(anchor): a way to show a <dialog>, anchored to a specific
   element on the page.

 - <dialog>.showModal(): a way to make a <dialog> modal.

 - <dialog>.close(returnValue): a way to close a <dialog>.

 - inert="": a way to disable an entire subtree, without necessarily
   making the elements in that subtree appear disabled (e.g. the way that
   controls behind a modal dialog are "disabled" without appearing that
   way, in traditional UIs).

 - <dialog oncancel="">: called when the user hits Escape on a modal
   <dialog>, can be cancelled to make the dialog not close.

 - <dialog onclose="">: called when the dialog closes.

 - <form method=dialog>: a way to use <form> for completely client-side
   interactions, including form validation, without having to worry about
   the form submitting. (Until browsers support this, you'll have to also
   specify something like action="javascript:void(0)", unfortunately.)

These features were based on discussions on this list (some of which
are below), but also on the results of looking for existing use cases,
some of which are documented on this wiki page:

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

The Fullscreen specification, also discussed on this list recently,
defines some of the features upon which these are built. Thanks to Anne
and Tantek in particular for working on that spec.


On Tue, 20 Mar 2012, Adam Barth wrote:
> On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 19 Mar 2012, Jochen Eisinger wrote:
> >>
> >> 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

All these issues are avoided by <dialog>'s showModal(), which is
intrinsically async (all it does is disable the UI on the rest of the
page).


> 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">
   <form method=dialog>
    Are you sure you want to order the widget?
    <input type=button value="Send" onclick="sendOrder()">
    <input type=button value="Cancel" onclick="cancelOrder()">
   </form>
  </dialog>
  <script>
   [...]
   document.getElementById('orderConfirm').showModal();
  </script>

I don't think it's "significantly" more complicated, especially given the
gains.


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

Well, on Mac you shouldn't have an "Ok" button at all, it should be "Send"
or some such. So this problem exists with confirm() also.


On Tue, 20 Mar 2012, Boris Zbarsky wrote:
> 
> Perhaps confirm() should take (optional) labels for the two buttons?

If we were extending confirm(), that might make sense. However, as Maciej
says:

On Wed, 21 Mar 2012, 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 [...] 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.

Indeed. Most of the examples on the wiki page I cite above would be
non-starters with confirm(), even if we extended it with button labels.


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

Indeed.


On Thu, 29 Mar 2012, Darin Fisher wrote:
> 
> 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).

Sure, but they couldn't be anchored like <dialog> can, couldn't be styled
like <dialog> can, etc. Anything but the most basic dialogs requires using
something more elaborate than these methods, so why not just start with
the more elaborate solution, especially since it's not that complicated?


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

If they don't care about loss of customization, why do we think they care
about the other problems?


On Thu, 29 Mar 2012, Darin Fisher wrote:
> 
> 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.

The modal variant of <dialog> handles this (there's a stack of active
modal dialogs).


On Tue, 20 Mar 2012, Darin Fisher wrote:
>
> 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.

With <dialog> it's not that much code.


On Thu, 5 Apr 2012, Sean Hogan wrote:
> On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
> > On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan<shogun70@westnet.com.au>  wrote:
> > > 
> > > Could it default to a "top" layer, but optionally be given a 
> > > z-index?
> >
> > Can you describe a use-case for putting the ::backdrop somewhere other 
> > than directly underneath the dialog/fullscreen element?
> 
> So that a menu-bar in the page can still be interacted with. An optional 
> z-index would be easier than calculating backdrop dimensions to not 
> overlap.

I've introduced an inert="" attribute that you can use in conjunction with
otherwise non-modal <dialog>s to make them seem modal with respect to some
parts of the page but not with respect to others.


> Look at my blog:
> 
> http://meekostuff.net/blog/
> 
> At the bottom is a simple site menu. If you click on the "contact" link 
> it pops up a dialog with a backdrop that covers the whole page... except 
> for the site menu. The dialog can be hidden by a "close" link in the 
> dialog, OR by clicking the "contact" link again.

You could do this by putting inert="" attributes on everything that isn't
that bottom bar (it affects entire subtrees, so you'd only have to put it
on the id=main <div>) while the contact dialog was up. You'd still have to
do the backdrop and z-index positioning yourself though in this case.

Received on Thursday, 12 April 2012 04:47:57 UTC