Re: [whatwg] Modal dialogs in HTML5
On Sat, 27 Dec 2008, Martin Atkins wrote: > Philipp Serafin wrote: > > timeless schrieb: > > > On Thu, Dec 25, 2008 at 8:29 PM, Philipp Serafin > > > wrote: > > > > > > > Well, you could still phrase it something along the lines of "The > > > > size of a popup document's viewport SHOULD be calculated using the > > > > CSS shrink wrap algorithm... etc etc". > > > > > > as an embedder of a browser for a small device, i do *not* want such > > > a requirement > > > > Hence why it would be a SHOULD and not a MUST. > > > > RFC 2119: "This word [...] mean[s] that there may exist valid reasons > > in particular circumstances to ignore a particular item [...]" > > If the spec author knows the "valid reasons", though, I would argue that > it's better for interop to just spell out the situations where the > requirement doesn't apply, rather than assume that implementors will > ignore a particular requirement. In this particular case, I think it's best just to leave it up to the browsers. Maybe it's something we should mention in the rendering section eventually, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modal dialogs in HTML5
Philipp Serafin wrote: timeless schrieb: On Thu, Dec 25, 2008 at 8:29 PM, Philipp Serafin wrote: Well, you could still phrase it something along the lines of "The size of a popup document's viewport SHOULD be calculated using the CSS shrink wrap algorithm... etc etc". as an embedder of a browser for a small device, i do *not* want such a requirement Hence why it would be a SHOULD and not a MUST. RFC 2119: "This word [...] mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item [...]" If the spec author knows the "valid reasons", though, I would argue that it's better for interop to just spell out the situations where the requirement doesn't apply, rather than assume that implementors will ignore a particular requirement.
Re: [whatwg] Modal dialogs in HTML5
timeless schrieb: On Thu, Dec 25, 2008 at 8:29 PM, Philipp Serafin wrote: Well, you could still phrase it something along the lines of "The size of a popup document's viewport SHOULD be calculated using the CSS shrink wrap algorithm... etc etc". as an embedder of a browser for a small device, i do *not* want such a requirement Hence why it would be a SHOULD and not a MUST. RFC 2119: "This word [...] mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item [...]" Cheers, Philipp Serafin
Re: [whatwg] Modal dialogs in HTML5
On Thu, Dec 25, 2008 at 8:29 PM, Philipp Serafin wrote: > Well, you could still phrase it something along the lines of "The size of a > popup document's viewport SHOULD be calculated using the CSS shrink wrap > algorithm... etc etc". as an embedder of a browser for a small device, i do *not* want such a requirement
Re: [whatwg] Modal dialogs in HTML5
Ian Hickson schrieb:
On Thu, 18 Dec 2008, Philipp Serafin wrote:
I think it would be a good idea to spec this algorithm as well then.
The algorithm I described is basically CSS' "shrink wrap" algorithm. But
we can't really require it, as it assumes that the OS has windows. My
desktop, for example, doesn't have resizable windows, it only has tabs (I
use the 'ion' window manager).
Well, you could still phrase it something along the lines of "The size
of a popup document's viewport SHOULD be calculated using the CSS shrink
wrap algorithm... etc etc".
All I really just want is to make sure browsers don't use today's
implentations. If you open a popup/modal dialog today and don't specify
a size, you usually end up with an arbitrary default size or even a
full-fledged second browser window the size of your screen - both pretty
ill-fitted for the use-cases of showModalDialog() IMO.
Example:
data:text/html,onclick="window.showModalDialog('data:text/html,height:100; border: 1px solid black;\'>Awkward-sized dialog
box');">Click me!
You still might want to keep the parameter for back compat though and
just mark it as "deprecated". (Your algorithm would deform existing
popup windows that assume their lengthy descriptions get line-wrapped
automatically.)
We'll probably define it in the "obsolete APIs" section in due course.
cool!
Regards,
Philipp Serafin
Re: [whatwg] Modal dialogs in HTML5
On Thu, 18 Dec 2008, Philipp Serafin wrote: > > I think it would be a good idea to spec this algorithm as well then. The algorithm I described is basically CSS' "shrink wrap" algorithm. But we can't really require it, as it assumes that the OS has windows. My desktop, for example, doesn't have resizable windows, it only has tabs (I use the 'ion' window manager). > You still might want to keep the parameter for back compat though and > just mark it as "deprecated". (Your algorithm would deform existing > popup windows that assume their lengthy descriptions get line-wrapped > automatically.) We'll probably define it in the "obsolete APIs" section in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modal dialogs in HTML5
Ian Hickson schrieb: On Thu, 18 Dec 2008, Philipp Serafin wrote: There is no reasoneable "default size" the page could adjust to. If the author can't specify the size of a popup/dialog, what algorithm should the UA use to find out the correct optimal size? Lay out the page at infinite height and width, then shrink the width until you get to the narrowest width that doesn't cause any overflow or line wrapping, then shrink the height until you get to the shortest height that doesn't cause overflow, then center it over the originating window. Point taken. In that case, if you really really needed, you could even still control the size explicitely via the width ang height CSS properties. I think it would be a good idea to spec this algorithm as well then. You still might want to keep the parameter for back compat though and just mark it as "deprecated". (Your algorithm would deform existing popup windows that assume their lengthy descriptions get line-wrapped automatically.) Regards, Philipp Serafin
Re: [whatwg] Modal dialogs in HTML5
On Thu, 18 Dec 2008, Philipp Serafin wrote: > > There is no reasoneable "default size" the page could adjust to. If the > author can't specify the size of a popup/dialog, what algorithm should > the UA use to find out the correct optimal size? Lay out the page at infinite height and width, then shrink the width until you get to the narrowest width that doesn't cause any overflow or line wrapping, then shrink the height until you get to the shortest height that doesn't cause overflow, then center it over the originating window. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modal dialogs in HTML5
Ian Hickson schrieb: On Wed, 17 Dec 2008, João Eiras wrote: While I myself don't find any decent use case for positioning the window, I think sizing the popup is a common and useful use case,besides controlling other aspected already covered by window.open(). Because the behavior for the features argument in window.open() and showModalDialog are similar (if not equal), I would recommend adding it to showModalDialog for the sake of normalization (you could link one spec to the other) and because UA would eventually reuse the implementation of window.open for both cases, therefore not requiring extra work from scratch. I haven't specced it for window.open() either. I agree, absolute pixel values are not really any good to specifying the size in any environment that should run on more than one machine. However, how are you supposed to control the size of your dialog otherwise? A normal web page is resized to fit into the window, and not vice versa, because the user usually has the browser open before he navigates to a page and constant resizing of the browser window would be irritiating to put it mildly. But this is not the case with popup/dialog windows. (At least the cases where they are not abused brutally) There is no reasoneable "default size" the page could adjust to. If the author can't specify the size of a popup/dialog, what algorithm should the UA use to find out the correct optimal size? As an example, many rich text editors use modal dialogs to specify font settings, etc. The HTML in the dialogs could be displayed in a normal-sized browser window effortlessy. However, it would look pretty silly. Regards, Philipp Serafin
Re: [whatwg] Modal dialogs in HTML5
On Wed, 17 Dec 2008, João Eiras wrote: > > While I myself don't find any decent use case for positioning the > window, I think sizing the popup is a common and useful use case,besides > controlling other aspected already covered by window.open(). Because the > behavior for the features argument in window.open() and showModalDialog > are similar (if not equal), I would recommend adding it to > showModalDialog for the sake of normalization (you could link one spec > to the other) and because UA would eventually reuse the implementation > of window.open for both cases, therefore not requiring extra work from > scratch. I haven't specced it for window.open() either. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Modal dialogs in HTML5
On , Ian Hickson wrote: On Mon, 28 Apr 2008, Joao Eiras wrote: What happened to the 3rd parameter (sFeatures) ? http://msdn2.microsoft.com/en-us/library/ms536759.aspx This parameter is needed to specific the window features (size, position, ...). I couldn't find any features that I could justify specifying, so I omitted it. IMHO the UA should determine the size and position automatically; why would the author specify them? The author has no way to know what a reasonable value is. While I myself don't find any decent use case for positioning the window, I think sizing the popup is a common and useful use case,besides controlling other aspected already covered by window.open(). Because the behavior for the features argument in window.open() and showModalDialog are similar (if not equal), I would recommend adding it to showModalDialog for the sake of normalization (you could link one spec to the other) and because UA would eventually reuse the implementation of window.open for both cases, therefore not requiring extra work from scratch.
Re: [whatwg] Modal dialogs in HTML5
On Mon, 28 Apr 2008, Jo�o Eiras wrote: > > What happened to the 3rd parameter (sFeatures) ? > http://msdn2.microsoft.com/en-us/library/ms536759.aspx > This parameter is needed to specific the window features (size, position, > ...). I couldn't find any features that I could justify specifying, so I omitted it. IMHO the UA should determine the size and position automatically; why would the author specify them? The author has no way to know what a reasonable value is. > Also, IE supports the properties dialogLeft, dialogWidth, dialogTop and > dialogHeight. Two of these can be read from innerWidth and innerHeight, > while the other two are irrelevant, and hardly useful for a webpage. > But, omitting these from the spec will create implementation > discrepancies. Probably you could add an extra section with features > that were purposely left out of the spec ? These are issues for Anne's CSSOM draft (along with innerWidth, etc). I recommend raising these issues with him. (I'm not sure which working group is the appropriate one for that draft.) > I've built some time ago a comprehensive testcase (it's attached), to > test IE's showModalDialog implementation, and besides what is common > sense, IE drops hashes from the url which is passed to showModalDialog, > and IE truncates, on purpose, the dialogArguments parameter to 4096 > chars, if it's a string. I see no possible reasoning for these design > choices. Fair enough. I've not required these in the spec. > Regarding the spec: > - about step 1. : you could mention that showModalDialog might be blocked by > popup blockers too, which is easier to understand for the crowd. Done. > - about step 3. : there's this clause "from running scripts". Well > showModalDialog blocks so all script execution must be halted while > showModalDialog does not return. So is this wording correct ? It doesn't block scripts in other windows or workers. > - about step 8. : you could add "the browing context can signal the UA to > terminate, e.g. calling window.close()" I haven't defined window.close() yet, but hen I do, I'll mention it here too. > Another thing: while the use cases for showModelessDialog can already be > covered by window.open(), there is a difference in behavior: > - window.open creates a new window, which can be lose focus, and go behind > it's opener window. > - showModelessDialog creates a new popup window, which can too lose focus, > but will never go behind it's opener. It'll say always in front of it. That seems to be up to the user agent. For example in Chrome new windows don't go behind the window that opened them by default. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [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: [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 model
Re: [whatwg] Modal dialogs in HTML5
Na , Ian Hickson <[EMAIL PROTECTED]> escreveu: This is a first draft. It has issues, I'm sure. Let me know what I should fix... Hi! What happened to the 3rd parameter (sFeatures) ? http://msdn2.microsoft.com/en-us/library/ms536759.aspx This parameter is needed to specific the window features (size, position, ...). Also, IE supports the properties dialogLeft, dialogWidth, dialogTop and dialogHeight. Two of these can be read from innerWidth and innerHeight, while the other two are irrelevant, and hardly useful for a webpage. But, omitting these from the spec will create implementation discrepancies. Probably you could add an extra section with features that were purposely left out of the spec ? I've built some time ago a comprehensive testcase (it's attached), to test IE's showModalDialog implementation, and besides what is common sense, IE drops hashes from the url which is passed to showModalDialog, and IE truncates, on purpose, the dialogArguments parameter to 4096 chars, if it's a string. I see no possible reasoning for these design choices. Regarding the spec: - about step 1. : you could mention that showModalDialog might be blocked by popup blockers too, which is easier to understand for the crowd. - about step 3. : there's this clause "from running scripts". Well showModalDialog blocks so all script execution must be halted while showModalDialog does not return. So is this wording correct ? - about step 8. : you could add "the browing context can signal the UA to terminate, e.g. calling window.close()" Another thing: while the use cases for showModelessDialog can already be covered by window.open(), there is a difference in behavior: - window.open creates a new window, which can be lose focus, and go behind it's opener window. - showModelessDialog creates a new popup window, which can too lose focus, but will never go behind it's opener. It'll say always in front of it. Use cases ? Consider you have a web application, and some help documents. While you have the main application open, you can open a dialog with a help manual and continue to work on the application while you have the manual on top, without the user needing to fiddle with windows and/or tabs. Implementing this is pretty straightforward. MS spec on showModelessDialog: http://msdn2.microsoft.com/en-us/library/ms536761.aspx Cheers. Title: testcase FAILED (script did not run)
[whatwg] 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 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:
>
