RE: Modal dialogs in HTML5
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 <[EMAIL PROTECTED]> 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
Re: Modal dialogs in HTML5
The shaded page, no doubt about it. The shaded page lets me close that window/tab. The shaded page doesn't clutter my windows task bar. The shaded page doesn't interfere if I'm busy in some other app or tab at the time. / Jonas João Eiras wrote: What would you rather prefer: - a native window which you (or your UA) can easily control ? - a shaded page with some floating content which you can't close at will or control ? I obviously agree with the downside of having either modal or non-modal window begin opened from webpages, but there are alternatives, and many can reduce user experience and anoy developers with extra layers of libraries and/or APIs. There's little you can do againast it :p Jonas Sicking <[EMAIL PROTECTED]> escreveu: 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. 2008/4/29, Bjoern Hoehrmann <[EMAIL PROTECTED]>: * João Eiras wrote: >The user can easily and quickly close the dialog and then the main >tab. Two clicks instead of one... don't be lasy :p. >That's a non issue. Unless the page raises another dialog of course, either maliciously or due to a coding problem. Preventing that from happening would probably not be easy without some surprises. Popup blockers are there to try to mitigate an evilness that was added a long time ago in a more innocent (naive?) time. Lets not add more such evilness. It only forces ourselves to struggle to find decent mitigation techniques, and forces developers to try to deal our mitigation techniques. / Jonas
Re: Modal dialogs in HTML5
What would you rather prefer: - a native window which you (or your UA) can easily control ? - a shaded page with some floating content which you can't close at will or control ? I obviously agree with the downside of having either modal or non-modal window begin opened from webpages, but there are alternatives, and many can reduce user experience and anoy developers with extra layers of libraries and/or APIs. There's little you can do againast it :p Jonas Sicking <[EMAIL PROTECTED]> escreveu: 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. 2008/4/29, Bjoern Hoehrmann <[EMAIL PROTECTED]>: * João Eiras wrote: >The user can easily and quickly close the dialog and then the main >tab. Two clicks instead of one... don't be lasy :p. >That's a non issue. Unless the page raises another dialog of course, either maliciously or due to a coding problem. Preventing that from happening would probably not be easy without some surprises. Popup blockers are there to try to mitigate an evilness that was added a long time ago in a more innocent (naive?) time. Lets not add more such evilness. It only forces ourselves to struggle to find decent mitigation techniques, and forces developers to try to deal our mitigation techniques. / Jonas
Re: Modal dialogs in HTML5
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. 2008/4/29, Bjoern Hoehrmann <[EMAIL PROTECTED]>: * João Eiras wrote: >The user can easily and quickly close the dialog and then the main >tab. Two clicks instead of one... don't be lasy :p. >That's a non issue. Unless the page raises another dialog of course, either maliciously or due to a coding problem. Preventing that from happening would probably not be easy without some surprises. Popup blockers are there to try to mitigate an evilness that was added a long time ago in a more innocent (naive?) time. Lets not add more such evilness. It only forces ourselves to struggle to find decent mitigation techniques, and forces developers to try to deal our mitigation techniques. / Jonas
RE: Modal dialogs in HTML5
On Tue, 29 Apr 2008, Travis Leithead wrote: > > >> 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. > > 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. I totally agree. Please invent a time machine and go back to Microsoft about 10 years ago and tell them not to invent showModalDialog(). :-) At this point, browsers have to support it, there's too much content out there that uses it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Modal dialogs in HTML5
* 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. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Modal dialogs in HTML5
> Unless the page raises another dialog of course For that there are popup blockers. The user must click something for another popup to open. 2008/4/29, Bjoern Hoehrmann <[EMAIL PROTECTED]>: > * João Eiras wrote: > >The user can easily and quickly close the dialog and then the main > >tab. Two clicks instead of one... don't be lasy :p. > >That's a non issue. > > > Unless the page raises another dialog of course, either maliciously or > due to a coding problem. Preventing that from happening would probably > not be easy without some surprises. > > -- > Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de > Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de > 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ >
Re: Modal dialogs in HTML5
* João Eiras wrote: >The user can easily and quickly close the dialog and then the main >tab. Two clicks instead of one... don't be lasy :p. >That's a non issue. Unless the page raises another dialog of course, either maliciously or due to a coding problem. Preventing that from happening would probably not be easy without some surprises. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Modal dialogs in HTML5
The user can easily and quickly close the dialog and then the main tab. Two clicks instead of one... don't be lasy :p. That's a non issue. It's much more preferable to have a native performant solution than relying on bloated js libraries, or code everything yourself. 2008/4/29, Travis Leithead <[EMAIL PROTECTED]>: > > >> 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. > > > 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. > >
RE: Modal dialogs in HTML5
>> 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. 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.
RE: 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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
> Sent: den 27 april 2008 10:59
> To: [EMAIL PROTECTED]
> Cc: Web APIs WG (public)
> Subject: Modal dialogs in HTML5
>
>
>
> On Fri, 27 Apr 2007, Jon Barnett wrote:
> > On 4/26/07, Ian Hickson <[EMAIL PROTECTED]> 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
> s for each
> part of the app, and all but the current 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 mode
