[whatwg] Modal dialogs in HTML5

If I understand it correctly, the suggested sections and "irrelevant" 
attribute would make dialogs work quite like current modal HTML 
dialogs from various js libs (the latter making use of backdrops to 
hinder access to original page content) as new content from the same 
page is swapped into view "in front" of the original content.
The modality comes natural when the original content is swapped out
from view and only the dialog content is accessible.

Though, I wonder if these two cases are addressed by sections/
"irrelevant":

1. See-through-view modality
Is it possible to "pop a dialog" on top of (while still showing) the 
original content, but hindering interaction with it? (much like what 
current js libs offer with their dialog classes)

2. Unload modality
Most modality discussed so far has been about the view modality, ie
disallowing the user from accessing the original page content until
the dialog has been dismissed. Browser modality may also be about
not letting the browser unload/reload the page until a dialog has 
been dismissed (eg "do you want to save before closing the window?").
Is there any way to force a user to respond to a modal dialog
section before unloading the page?
If not, ideally a generic modality feature could be added to assist
both sections and current style HTML dialogs in achieving this
unload modality.

Best regards
Mike Wilson

> -----Original Message-----
> From: public-webapi-request at w3.org 
> [mailto:public-webapi-request at w3.org] On Behalf Of Ian Hickson
> Sent: den 27 april 2008 10:59
> To: whatwg at whatwg.org
> Cc: Web APIs WG (public)
> Subject: Modal dialogs in HTML5
> 
> 
> 
> On Fri, 27 Apr 2007, Jon Barnett wrote:
> > On 4/26/07, Ian Hickson <ian at hixie.ch> wrote:
> > > On Sun, 26 Jun 2005, Karl Pongratz wrote:
> > > >
> > > > I had a short look at the webforms and web applications 
> > > > specification at whatwg.org, I didn't find anything 
> about modal and 
> > > > modeless windows. If there is anything to improve for 
> html, xhtml, 
> > > > xforms and compound documents, then, in my opinion, the first 
> > > > missing feature that comes into my mind is the lack of 
> modal and 
> > > > modeless windows.
> > > 
> > > I've now added window.open(), irrelevant="", and target="" to the 
> > > specification, which should provide various ways of obtaining the 
> > > effect you're looking for. For example, with 
> irrelevant="" you can 
> > > hide the content you want to disable, and force the 
> "modal" aspect of 
> > > the application to be responded to before reshowing the 
> other parts.
> > 
> > Can I ask how that would work with a dialog?  Would it be like this?
> > 
> > myframeddocument.designMode = "on";
> > mytoolbar.hyperlinkButton.onclick =  function() {
> > myframeddocument.body.irrelevant = true;
> > var dialog = window.open("hyperlinkDialog.html");
> > // a dialog where the user may either enter a URL or choose 
> from a preset
> > list of pages on his site
> > 
> > dialog.onunload = function() {
> >  processHyperlinkSelections();
> >  myframeddocument.body.irrelevant = false;
> > }
> > }
> > 
> > Is that really the best way?
> 
> No, I meant everything within the one document, with 
> <section>s for each 
> part of the app, and all but the current <section> having 
> irrelevant="" 
> set.
> 
> 
> > Would that keep "dialog" on top of the main browser window 
> until it's 
> > dismissed?
> 
> You should only use one browser window ever, as a Web app author.
> 
> 
> > I used the WYSIWYG example because I think it's a good case where 
> > authors really want some sort of modal dialog that's 
> synchronous in the 
> > opener document's javascript.  Is there a better way to handle that?
> > 
> > I'm also curious why the "features" argument of window.open 
> is supposed 
> > to "have no effect".  That's something I can search the 
> archives for on 
> > my own if it's been asked and answered.
> 
> Because none of the features that browsers support are things that 
> actually should be supported, as they are not things that 
> help the user.
> 
> 
> On Fri, 27 Apr 2007, Thomas Broyer wrote:
> > 
> > If I correctly understood Ian's proposal, the "best way" 
> would be to not 
> > use another window.
> > 
> > 1. put the content of hyperlinkDialog.html within the "current" page
> > (or eventually load it within an iframe) and make it irrelevant=true
> > (let's call this the "hyperlink editing section")
> > 2. when you click the "hyperlink" toolbar button, make the 
> "hyperlink
> > editing section" irrelevant=false
> > 3. when the OK or Cancel button inside the "hyperlink 
> editing section"
> > is clicked, do what's needed and switch the section back to
> > irrelevant=true
> 
> Pretty much.
> 
> 
> On Sun, 27 Jan 2008, Karl Pongratz wrote:
> > 
> > You say:
> > "Notwithstanding the features that make this possible, I 
> have to say that  in
> > general Web applications on the Web should not be written 
> as if they are
> > desktop applications."
> > 
> > 1.) We actually miss web application models. Do you know of 
> any where 
> > they are defined, though some which don't have any quirks? 
> Application 
> > models where the web browser back/next and reload button 
> doesn't harm 
> > anything? Maybe its time to fix this issues by defining web 
> application 
> > models (single page web applications and multi-page web 
> applications) 
> > which do not suck. It would be great if someone could point 
> me to this 
> > information, I would i.e. be interested of how they deal with the 
> > problem with un-saved data if the user closes the web browser.
> 
> I don't know off hand of good resources on the matter, but 
> this would be 
> an interesting area to document.
> 
> 
> > 2.) Modal Windows / Modal Elements
> > What we actually need are modal elements inside a page. 
> Even applications with
> > minor editing features such as the Google Reader uses modal 
> windows, in this
> > particular case a prompt().
> > I would guess modal elements will be supported sooner or 
> later. They will
> > replace the current alert() and prompt() function.
> > Maybe modal elements (or modal forms) are already part of HTML5?
> 
> Well, we have disabled="" and irrelevant="", what else were 
> you thinking 
> of?
> 
> 
> On Fri, 1 Jul 2005, Sanghyeon Seo wrote:
> >
> > 
> http://msdn.microsoft.com/workshop/author/dhtml/reference/meth
> ods/showmodaldialog.asp
> 
> On Sun, 3 Sep 2006, Anders Rundgren wrote:
> >
> > [...] it is very hard to create certain types of 
> applications without 
> > having modal dialogs.  AFAIK the existing alert() box is 
> already modal 
> > (at least in MSIE) so modality is well established.
> 
> On Tue, 18 Mar 2008, Travis Leithead wrote:
> > 
> > ...but why [did WebKit implement the showModalDialog()] API and not 
> > showModelessDialog too? I'd be interested to know the 
> rationale for this 
> > decision on WebKit's part.
> > 
> > Also, was openDialog considered (from FF)?
> 
> On Tue, 18 Mar 2008, Boris Zbarsky wrote:
> > 
> > My guess (not being a Safari implementor) is that there 
> isn't much call 
> > for showModelessDialog because you can get pretty close with 
> > window.open().  That was certainly the reason Gecko didn't 
> implement 
> > it...
> > 
> > > Also, was openDialog considered (from FF)?
> > 
> > Note that Gecko 1.9 (Firefox 3) will implement 
> showModalDialog as well.
> 
> On Tue, 18 Mar 2008, Maciej Stachowiak wrote:
> > 
> > We've been shipping showModalDialog for years on Mac, but I 
> think it 
> > didn't work on Windows in our betas. We had to add it for 
> certification 
> > with certain "enterprise" web applications years ago.
> > 
> > We've never had a request for showModelessDialog or equivalent 
> > functionality (as far as I know).
> > 
> > > Also, was openDialog considered (from FF)?
> > 
> > We asked the ISVs who wanted a way to do a modal dialog and they 
> > preferred the IE API. Neither seemed technically better or 
> worse as far 
> > as we could tell.
> 
> Against my better judgement, I have specced out showModalDialog().
> 
> (We clearly need to spec it somewhere if everyone's going to be 
> implementing it, otherwise we'll have an interop nightmare -- 
> and indeed 
> showModalDialog() works differently in all three browsers 
> mentioned above. 
> I figured HTML5 was the right place since showModalDialog() interacts 
> directly with the navigation algorithm and browsing contexts, 
> which are 
> currently defined in HTML5.)
> 
> This is a first draft. It has issues, I'm sure. Let me know 
> what I should 
> fix...
> 
> -- 
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
> 
>

Received on Tuesday, 29 April 2008 05:38:57 UTC