W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

RE: Modal dialogs in HTML5

From: Mike Wilson <mikewse@hotmail.com>
Date: Wed, 30 Apr 2008 17:02:49 +0200
Message-ID: <BAY116-DAV87238CDE3024B804FE260A4D80@phx.gbl>
To: "'Web APIs WG \(public\)'" <public-webapi@w3.org>
Message-ID: <01e501c8aad3$41914540$0a01a8c0@mikedeskxp>

Bjoern Hoehrmann wrote:
> * Joćo Eiras wrote:
> >> Unless the page raises another dialog of course
> >
> >For that there are popup blockers.
> >The user must click something for another popup to open.
> 
> Of course there are solutions, but you might ultimately be asking the
> wrong question to begin with. If the problem is simply 
> avoiding loss of
> date when the user closes a window, you could simply save the changes
> without asking the user (in a manner that does not override the old
> state). That would have its own problems, and so would alternate so-
> lutions, the decision is which set of problems you prefer; that there
> are known workarounds for modal dialog problems does not mean 
> we should have those problems in the first place.

I agree you will get a different set of problems depending on which 
way you decide to go, but I don't think we should give up so easy on
this one. The aim for the HTML5 is to better support Web Applications. 
Web sites may do well without solid dialog support but IMO Web Apps do 
not. I also do not think it is a good thing to try to be the Thought
Police of the web, restricting how Web Apps should be designed, as that
requires you to consider and imagine every possible future Web App.

So, while trying to avoid suggesting specific solutions these are the 
requirements I would like to mention for dialogs:
(My comments within [].)

1. Offer several ways to show a modal dialog:
   a. A separate native window for dialog contents (showModalDialog).
      [This is already implemented in current browsers.]
   b. Dialog contents fully replacing main window contents.
      [My understanding is that this is implemented by HTML5 sections
      with the "irrelevant" attribute.]
   c. Dialog contents floated above shaded main window contents.
      [Currently implemented by a number of js libs using CSS
      positioning tricks.
      Q: Could something like this get native support in HTML5?]
   d. Window.alert() and Window.prompt().
      [These are already implemented in current browsers.]
   e. "Leaving page warning" dialog as a result of a non-false
      return from an onbeforeunload event handler.
      (http://pro-thoughts.blogspot.com/2006/03/onbeforeunload-event.html)
      [This is already implemented in current browsers but could
      possibly be replaced in the future by the other dialog types
      if the modal-on-unload concern is resolved.]

2. Allow HTML formated contents in dialogs.
   [This is implicit for (1a,b,c) and IMO not needed for (1d) but 
   (1e) would benefit from new support to make such a dialog blend in
   with the rest of a site.]

3. Hinder the user from interacting with main window contents while 
   dialog is shown.
   [This is implicit or already natively implemented for (1a,b,d,e) 
   but requires new support for (1c).]

4. Exhibit modal behaviour in script so event handler execution is 
   "paused" at the point of modal call, and resumed when dialog is 
   dismissed.
   In particular, this is interesting for on[before]unload handlers to 
   let the user answer a prompt (f ex "Do you want to save?") before 
   unloading the page.
   [This is already implemented for (1a,d,e) but requires new support
   for (1b,c).]

5. Allow the user to forcably abort/cancel undesired modal interactions
   through a browser control, f ex the stop button.
   [This would resolve the issue with evil pages repeatedly popping
   modal dialogs at page unload mentioned above. In fact, the same 
   stop/abort command could also address problems users are having 
   today with pages that get stuck in long-running scripts or repeated 
   alert calls.]

Travis Leithead <travil@windows.microsoft.com> wrote:
> I'm not a big fan of allowing a web application to have that 
> level of control of a user's browsing experience (a web page 
> preventing a user from closing a tab, for example). The 
> desktop paradigm is like allowing a program to prevent the 
> user from restarting or shutting down the OS--seems like a 
> bad design decision.

Is this irony over your employer's products? :-)
(The bad scenario you are describing is exactly what happens if
you try to shut down Windows while having an unsaved document
open. You will get a dialog asking if you want to save and the
shutdown will be paused.)

Best regards
Mike Wilson
Received on Wednesday, 30 April 2008 15:03:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 April 2008 15:03:48 GMT