[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 sections 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
Re: [whatwg] postMessage feedback
On Sat, 26 Apr 2008, Jeff Walden wrote: Ian Hickson wrote: I haven't changed the target of the event, it's still the Document object. This is a little odd, though, would people rather I made it the body element with an auto-forward to the Window object, like the 'load' event and so forth? That would allow onmessage= handles to be written. I've mentioned this on IRC but should probably mention it here so it's in the record, so to speak. I don't see a strong use case for an onmessage attribute. Event handler attributes are useful for quick little things, but accepting messages from other sites seems neither quick (aside from free-for-all walls I can't think of things you'd want to do that wouldn't be fairly involved) nor little (you need the origin check at a minimum, then you have to do whatever you're going to do, and it's a lot to stuff in an attribute -- and if you're just delegating to another method, why not just set the method as handler programmatically?). I don't think having to do it via script is particularly burdensome. On Sat, 26 Apr 2008, Maciej Stachowiak wrote: If anything this event should dispatch to the window, not the document, since that is what gets the postMessage call. But posting to the document and bubbling to the window seems ok too. On Sat, 26 Apr 2008, Jeff Walden wrote: The event currently doesn't bubble to accommodate event-source: http://lists.whatwg.org/htdig.cgi/commit-watchers-whatwg.org/2008/000436.html So right now, either you use a bubbling listener (capturing works too, although the web may end up dictating that that's a bug that won't be fixt) on the document or a capturing listener (ugh) on window or you don't get it. I'm not entirely sure why the event doesn't bubble for postMessage; it seems like a postMessage event doesn't necessarily have to do the same thing as an event-source event, but maybe there's precedent here that I don't know. As far as I can tell the event is dispatched at the document only because Opera's original implementation had postMessage on document. I sort of prefer dispatching to the window as well, but that change would have to be made ASAP to make Firefox 3. It's a one-line change (+30ish for addEventListener calls in tests, also easy to do), as is the bubbling change, but it's extraordinarily late for us to make these changes (async cuts it very, very fine as-is), and nobody would be happy if the spec converged on something that Firefox 3 didn't actually implement. On Sat, 26 Apr 2008, Maciej Stachowiak wrote: I hope this can be addressed soon, and I feel your pain. But in Safari 3.1 we actually dropped postMessage at the last minute because of too many spec changes, and the spec changed in major ways after Opera actually shipped their implementation, so it's not like changes here are unprecedented and certainly Firefox is not being singled out. (On the substance, I think dispatching to the window would be better based on your comments.) Changed to dispatch to the window. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: target=_reference
How about target=_guide instead? A reference is usually lengthy and unreadable; the designer should know better than to treat the poor user with a reference. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Paul Thomas Sent: Saturday, April 26, 2008 2:24 PM To: WHAT WG List Subject: [whatwg] Proposal: target=_reference Summary: I propose target=_reference, which would open a link in a secondary viewport, for example a closable pane at the bottom of a browser window. This would be much less annoying and intimidating than target=_blank. It could be used immediately for providing help, and for linking to privacy policies, terms of use, etc within forms. Eventually it could also be used for footnotes and endnotes.
Re: [whatwg] Proposal: target=_reference
Philip Taylor wrote on 27/04/08 18:30: ... IE6 supported target=_search and target=_media, to open pages in sidebars (closable panes at the side of the browser window). Nobody uses those target values (in 130K pages I see 3 pages with either), and http://msdn2.microsoft.com/en-us/library/ms534659(VS.85).aspx says _media was dropped in XP SP2 and _search was dropped in IE7 (for security reasons). _reference sounds functionally very similar, so how would it avoid those security problems The problem with _media and _search was that if you gave them an invalid URL, the resulting error page res://blahblahblah was in the My Computer zone, but could still be manipulated (e.g. have malicious code inserted in it) by the remote page. That could be avoided by not treating error pages as being in the My Computer zone. I guess Microsoft didn't bother with this because they knew that media was going to be, and search already was, handled differently in IE7 anyway. and why would it be more successful in practice? Because it would be cross-browser. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Error: 2nd example datetime for the time element
In section 3.10.10, the second example is: time datetime=2006-09-24 05:00 -7 However, the algorithm given in 3.2.4.2 for parsing date or time strings requires that the timezone hour offset be exactly 2 digits. (This is the same requirement ISO 8601 has.) Hence, the example as given is invalid according to the provided parser algorithm, since it has only 1 digit. Ernest Cline
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] DOM Storage feedback
On Tue, 19 Feb 2008, Ralf Stoltze wrote: I found three more occurrences of global storage area in the current version, in 4.10.6.2 and 4.10.7.1. Fixed. And a minor typo in 4.10.5: hte -- the Thanks. Fixed. On Thu, 13 Mar 2008, Dave Camp wrote: 4.10.6.1 still talks about quotas being per-domain-setting-the-value vs. per-storage-area, this is no longer relevant. Fixed. On Fri, 21 Mar 2008, Sunava Dutta wrote: Meanwhile, we have feedback for the draft that we feel and hope will contribute to the existing repository of web developer's tools. Here are a few enhancements that we've implemented. We think these features are good for developers and want to add them to the spec. MSDN is being updated so for more details please refer to the API.http://msdn2.microsoft.com/en-us/library/cc197062(VS.85).aspx Storage.remainingSpace A straightforward and popular request, this API provides a script to check the remaining persistent storage spec available to it, in bytes. It's a very useful feature to allow pages to manage their store better. * Open Issue We currently return bytes but perhaps returning the number of characters is more useful? We'd love to hear thoughts here... The problem with this feature is that there are a number of ways to store data, and thus no way to know exactly how much data can be stored. For example, if the UA stores data in UTF-8 characters, the number of characters left to store will vary based on what characters are to be stored. Similarly, if the UA stores data in a compressed fashion, the number of bytes will vary based on how compressible the data is. Furthermore, we don't want to preclude user agents from dynamically increasing the amount of available storage based on user actions, for example the UA could automatically increase the storage every time the user interacts with the page, or could prompt the user to increase the storage when it gets to 80%. Thus this API really can't easily work in an interoperable fashion. Clear All APIhttp://msdn2.microsoft.com/en-us/library/cc288131(VS.85).aspx Storage.clear() An obvious benefit for the persistent store, unlike removeItemhttp://msdn2.microsoft.com/en-us/library/cc197047(VS.85).aspx, this API removes all key/value pairs accessible to that script without requiring costly iteration over all data entries. Added. Asynchronous model for DOM Storage:http://msdn2.microsoft.com/en-us/library/cc288674(VS.85).aspx The spec calls for atomic setItem() and removeItem() with respect to changes to the data storage area. This is valuable since it ensures that data is written to disk successfully. One of the major differences today between what we've implemented is that we went down an asynchronous path. This is because there are significant performance advantages if committing to the disk can be delayed while providing the data instantly from memory. Our model is exposed the same as a synchronous model to the web developer so there should be no differences to the developer who is interested in programming it using no new APIs other than that specified in the HTML 5.0 spec. Here are some of the reasons why the asynchronous model was chosen: 1. It offers much better performance without sacrificing the persistence to disk -- we will fire an event to confirm commit so web applications can listen to the event when persistence is a concern. 2. Our customer outreach leads us to believe that the DOM Storage is primarily used as local cache to improve responsiveness. The performance cost of synchronous storage in our opinion outweighs the need for guaranteed persistence. 3. It avoids a possible hang in the UI thread if the operation takes long time and therefore makes the browsing experience more fluid. The API is designed in such a way that UAs can implement a lazy commit on the back end, but this should not be exposed to the author -- there is no reason for the author to need to know whether the data is in RAM, flash storage, disk storage, remote tape storage, or whatever. Hence we created an async model. As far as the web developer is concerned, the data will be available immediately from memory when the onstorage event it fired so the behavior is the similar and no new APIs are needed, hence its backwards compatible with other implementations. In addition, an onstoragecommit event is fired for developers who want to ensure the data is persisted to disk successfully. Begin/Commithttp://msdn2.microsoft.com/en-us/library/cc197036(VS.85).aspx Storage.begin() Storage.commit() It's an application level concept that web authors who want a set of values to be committed at once can use. Data is either committed in its entirety (batch commit) or not. This is especially critical given that DOM Storage is primarily used for name/value pair operations and many applications need a set of name/value pairs to define a
Re: [whatwg] xml:space
I haven't done anything with xml:space. It doesn't do anything, and it's not an HTML5 thing, so as far as I can tell it is out of scope for HTML5. On Mon, 22 Jan 2007, Henri Sivonen wrote: Since this editor artifact is harmless in browsers and useful in editors, it would be nice if the spec made it conforming at least on the pre element in XHTML5. Suggested text: The xml:space attribute may be used on XHTML elements of XML documents. Authors must not use the xml:space attribute in HTML documents. The xml:space attribute, if present, must have the literal value default or the literal value preserve. The meaning of this attribute is outside the scope of this specification. If that's too permissive, here's what would minimally cover my use case: In XHTML (but not in HTML), the element pre may have the attribute xml:space. If the attribute is present, the value of the attribute must be preserve. The first conforms to XML 1.0 for sure. The latter may not exactly, depending on spec interpretation. I don't see why we should special-case this particular harmless non-HTML feature, and not any number of other harmless non-HTML features. If another specification wants to define something, then it's up to that specification to define when it can be used. On Tue, 23 Jan 2007, Henri Sivonen wrote: (As a practical matter, it would be nice to explicitly remind conformance checker developers that the attribute is conforming. Otherwise, it is easily forgotten. :-) Forgeting it seems fine to me... On Tue, 23 Jan 2007, liorean wrote: Well, considering the purpose of XHTML (main purpose is presentation for humans, no?) is there any reason to NOT just set it to default to preserve on the html element, fixed to preserve on the script, style, pre and textarea elements and have it implied through an entity for all other elements? Style sheets can change whether presentation of whitespace is collapsed or not. By default, the whitespace is collapsed but for the pre element it's conserved, but that can overridden by user or author style sheets. But whitespace that is structurally collapsed at the XML level cannot be restored for presentation by the style sheet, so this whitespace is lost from ever being presented as it appeared in the document. xml:space doesn't allow whitepsace to be collapsed at the XML level as far as I can tell. On Tue, 23 Jan 2007, Anne van Kesteren wrote: Regarding whether or not HTML5 should mention it. It seems the intention of the XML specification is that you have to say it's allowed: In valid documents, this attribute, like any other, MUST be declared if it is used. Opinions probably vary on this. Valid in XML is only relevant for DTDs. On Tue, 23 Jan 2007, liorean wrote: Hmm, reading the relevant part of the XML1.0 spec again, I see you're right. So, it would seem to me that it's an attribute describing whitespace semantics in content, not a structural attribute like I thought. So, say you have a poetry:poem element, but where the element semantics doesn't specify whether whitespace is important in the poem or not (it might be, but that depends on the poem content), you can specify it in that attribute. Seems like it'd be better for the spec itself to define the semantics of its elements rather than depend on the author to specify the attribute... On Tue, 23 Jan 2007, Martin Atkins wrote: Presumably its primary purpose is to act as a signal to generic XML tools — that don't have any special knowledge about XHTML — that they should not screw around with the whitespace inside PRE, etc. One obvious example of such a tool is an XML pretty-printer. While an HTML pretty-printer like HTML Tidy can have rules hard-coded into it, this is not true of a non-validating XML formatter unless it is specifically written for XHTML. It seems that given the importance of XHTML, we can expect pretty printers to be written for it. On Tue, 23 Jan 2007, Henri Sivonen wrote: (And this isn't theoretical, either. I came across this issue when editing an XHTML document in oXygen.) File a bug with them. :-) On Tue, 23 Jan 2007, liorean wrote: How doesn't it? If the DTD allows it on all elements, you can put xml:space=preserve on all elements in the document that need it for the tools that don't use the external subset or namespace recognition On Wed, 24 Jan 2007, Henri Sivonen wrote: There's no DTD. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML syntax: comments before doctype and doctype sniffing
On Sun, 3 Dec 2006, Spartanicus wrote: Simon Pieters [EMAIL PROTECTED] wrote: The parsing section says that a comment before the doctype may trigger quirks mode. I'm assuming that this comment merely documents IE's current behaviour. Please ignore my other comment if I'm wrong. Therefore I think the syntax section shouldn't allow comments before the doctype (only space characters). There are valid reasons to kick IE into quirks mode whilst triggering standards mode in other browsers. There is existing content on the web that intentionally does this. Why would you want to deny an author who fully understands the issues from doing this? Once browsers implement HTML5, there won't be a way to trigger quirks in one browser and not another. We want all HTML5 documents to trigger standards mode. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
