[whatwg] Modal dialogs in HTML5

[Ian Hickson]

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/methods/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.   `._.-(,_..'--(,_..'`-.;.'