Re: [whatwg] Script-related feedback
Given that it is possible to do this from script, how common is it for people to do it from script? If it's very common, that would be a good data point encouraging us to do this sooner rather than later. 6 of the top 10 US web sites load scripts after the load event: eBay, Facebook, Bing, MSN.com, MySpace, and Yahoo. -Steve On 3/16/2010 5:05 PM, Ian Hickson wrote: On Tue, 3 Nov 2009, Brian Kuhn wrote: In section http://www.whatwg.org/specs/web-apps/current-work/#attr-script-async, it says: *Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run.* Has any thought been put into changing this for async scripts? It seems like it might be worthwhile to allow window.onload to fire while an async script is still downloading if everything else is done. On Fri, 6 Nov 2009, Brian Kuhn wrote: It seems to me that the purpose of async scripts is to get out of the way of user-visible functionality. Many sites currently attach user-visible functionality to window.onload, so it would be great if async scripts at least had a way to not block that event. It would help minimize the affect that secondary-functionality like ads and web analytics have on the user experience. On Wed, 10 Feb 2010, Jonas Sicking wrote: I'm concerned that this is too big of a departure from how people are used toscripts behaving. If we do want to do something like this, one possibility would be to create a generic attribute that can go on things likeimg,link rel=stylesheet,script etc that make the resource not block the 'load' event. On Thu, 11 Feb 2010, Steve Souders wrote: I just sent email last week proposing a POSTONLOAD attribute for scripts. On Thu, 11 Feb 2010, Jonas Sicking wrote: Though what we want here is a DONTDELAYLOAD attribute. I.e. we want load to start asap, but we don't want the load to hold up the load event if all other resources finish loading before this one. On Fri, 12 Feb 2010, Brian Kuhn wrote: Right. Async scripts aren't really asynchronous if they block all the user-visible functionality that sites currently tie to window.onload. I don't know if we need another attribute, or if we just need to change the behavior for all async scripts. But I think the best time to fix this is now; before too many UAs implement async. On Fri, 12 Feb 2010, Nicholas Zakas wrote: To me asynchronous fundamentally means doesn't block other things from happening, so if async currently does block the load event from firing then that seems very wrong to me. On Fri, 12 Feb 2010, Steve Souders wrote: ASYNC should not block the onload event. Thinking of the places where ASYNC will be used, they would not want onload to be blocked. On Sat, 13 Feb 2010, Darin Fisher wrote: I don't know... to me, asynchronous means completes later. Precedence: XMLHttpRequest. On Sat, 13 Feb 2010, Boris Zbarsky wrote: [...] my real worry about making any loads that don't block onload: would web developers expect them to? On Sat, 13 Feb 2010, Brian Kuhn wrote: FWIW, loading scripts asynchronously with the Script DOM Element approach does not block window.onload in IE. In Chrome and Safari, the downloading blocks, but execution doesn't. In Firefox and Opera, downloading and execution blocks. So, it's pretty hard to say what web developers would expect with async scripts. I know that they will like having things like ads and analytics not block window.onload though. At the very least, we need that ability to make that happen. On Sat, 13 Feb 2010, Jonas Sicking wrote: Yeah, my big concern is what do developers expect. Having an explicit attribute for not blocking onload definitely follows the path of least surprise. Though having an explicit attribute does give Steve more things to evangelize, i.e. it'll probably lead to more pages firing onload later than they could. On Sat, 13 Feb 2010, Darin Fisher wrote: The thing is, almost all subresources load asynchronously. The load event exists to tell us when those asynchronous loads have finished. So, I think it follows that an asynchronous resource load may reasonably block the load event. (That's the point of the load event afterall!) I've changed the spec to fire 'DOMContentLoaded' without waiting for the async scripts, so that if you need this you can just listen for that event instead of 'load'. 'load' still waits for all scripts. 'DOMContentLoaded' still waits for deferred scripts. As far as I can tell this handles all the above (still makes sense, still consistent with the way other 'load' events work, but still lets you do things without waiting). On Wed, 30 Dec 2009, David Bruant wrote: The 6.8.1 Client identification starts with an explanation dealing with browser-specific bugs and
Re: [whatwg] global object in onmessage event? Really?
On Sat, 13 Feb 2010, David Flanagan wrote: Section 9.2.3, step 5 reads: Create an event that uses the MessageEvent interface, with the event name message, which does not bubble, is not cancelable, and has no default action. The data attribute must be set to the value of message clone, the origin attribute must be set to the Unicode serialization of the origin of the script that invoked the method, and the source attribute must be set to the script's global object. Is the source property really supposed to be the global object and not the WindowProxy object? I thought that the point of WindowProxy was that you were *never* supposed to be able to obtain a reference to the real global object. Good catch. Thanks. Fixed. (BTW, please name sections and steps rather than giving their numbers. The numbers change all the time and as there are multiple versions of the specs with different section numbers for the same text, it's unclear what section a number references.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Mistyping of title end tag causes white page
On Sat, 20 Feb 2010, Nikita Popov wrote: I noticed, that mistyping the ending title tag causes a white page and a title containing the whole source of the page (from the starting title tag on) in firefox3.6 with enabled HTML5 Parsing Algorithm. As I haven't read the the HTML5 Parsing Algorithm section, I don't know whether this is a misimplementation or is defined this way in the algorithm. Obviously this cannot be the expected behavior. The second title tag should be interpreted as a /title tag. On Mon, 22 Feb 2010, Henri Sivonen wrote: The only type of recovery that doesn't introduce even more problems would be first parsing until EOF and then rewinding to the title element start and reparsing until the next . Implementing the recovery strategy from the previous sentence would make the parser vulnerable to executability escalation attacks by forcing a premature EOF. (Granted, the attacks are rather contrived.) Consider: titletitlescriptalert(Attack code could go here!);/script /title ... EOF vs. titletitlescriptalert(Attack code could go here!);/script ... EOF In practice, IE doesn't reliably recover from this class of authoring error, so it's fair to believe that the Web doesn't depend on browsers recovering from this situation. So far, I haven't seen bug reports about this HTML5 behavior affecting pages on the Web. I have seen one report about a non-IE-oriented intranet page (Mozilla's own!). This is indeed the expected behaviour. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Prevent abuse of data-*
On Mon, 22 Feb 2010, Kornel Lesi�~Dski wrote: I'm wondering if data-* attributes should be renamed to priv-* to make it clearer that it's page's _private_ data. data- is such a nice generic prefix that I'm afraid sooner or later someone will start basing microformats-like markup on that. It's not a bad idea... Unfortunately data-* is already being used quite a lot and has been widely advertised, so we have to be careful with this. Anyone else have an opinion on this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebSocket bufferedAmount includes overhead or not.
On 05.03.2010, at 15:32, Alexey Proskuryakov wrote: for something no one should care about, as you implied above. From API perspective I do care. Web developers shouldn't need to know about the protocol, yet (s)he should be able to understand what bufferedAmount means. An explanation like it's how much data is buffered to be sent over network seems adequate to me. We have a suggested patch that implements the proposed new behavior for WebKit now, but I think that it adds unnecessary complexity, and puts limits on how we can refactor the code in the future. We need to remember frame boundaries for much longer, making it difficult to interface with general purpose networking code. I'd prefer sticking to the previously specified behavior. - WBR, Alexey Proskuryakov
Re: [whatwg] #13; expanding to LF
On Mon, 22 Feb 2010, Henri Sivonen wrote: HTML5 makes #13; expand to LF. What problem does this solve? None of Gecko, Presto, Trident or WebKit expand #13; to LF. (They all expand it to CR.) This makes the HTML5 parser fail http://mxr.mozilla.org/mozilla-central/source/layout/style/test/test_parse_rule.html This was apparently originally requested by Anne: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011689.html I'm fine with changing it back, assumine Anne's ok with it too. Anne? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Prevent abuse of data-*
2010/3/17 Ian Hickson i...@hixie.ch: On Mon, 22 Feb 2010, Kornel LesiÅ~Dski wrote: I'm wondering if data-* attributes should be renamed to priv-* to make it clearer that it's page's _private_ data. data- is such a nice generic prefix that I'm afraid sooner or later someone will start basing microformats-like markup on that. It's not a bad idea... Unfortunately data-* is already being used quite a lot and has been widely advertised, so we have to be careful with this. Anyone else have an opinion on this? I don't feel strongly that either name is better. Though I would not that priv- doesn't make things much clearer since it's totally undefined who it's private to. / Jonas
Re: [whatwg] Multiple file download
On Tue, 23 Feb 2010, Jose Fandos wrote: Currently there are implementations allowing multiple file upload without the need for flash or java applets. What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. Was wondering if this could be made part of the standard. If something like resource packages http://limi.net/articles/resource-packages/ were used, the server would still be sending one file which could be heavily compressed, letting the UA to decompress and display as if a bunch of files had been downloaded separately. If this needs a change to the specs, it seems like something that should be done either as a new type (e.g. multipart/archive) or some extension to HTTP. I don't think there's anything we should really do at the HTML level to support something like this. I would recommend developing a type that expands as you describe, and then approaching browser vendors directly to see if they would be interested in implementing that feature. Alternatively, you could suggest to browser vendors that they just implement a UI feature that, upon receiving an archive, offers to expand the archive automatically. Some already do (e.g. on Mac it's common for .dmg files to be automatically mounted -- effectively most Mac users are already experiencing what you're describing without any new features being needed, it just works). Another possibility is for browsers to offer UI that given a bunch of links will apply the same download settings to each one, so that the user can just drag-select a bunch of links and download them all with one or two clicks. In conclusion, this seems out of scope for this working group. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] summary tag to help avoid redundancy of meta description tag!?
I searched the list, and looked at the HTML5 briefly and found nothing, nor can I ever recall such. So this is both a question and a proposal. On my own site currently I mostly replicate the first paragraph of an article in my journal as the meta description, and write one up for other pages, usually replicating some of the content. I'm both looking for and want a solution to avoid such redundancy. The perfect solution would be a summary tag, if you look at the journal articles on my site you can imagine the first paragraph being done like this: psummaryThis is just an example, it's a replacement for the old meta description, and is a brief summary (description) of the page (content)/summary/p This way the first paragraph in a page would remain unchanged from how it is done today, and a search engine like Google or screen readers etc. would use the summary tag instead of the meta description (which is no longer needed at all in cases like this), if more than one summary tag the first is considered the page summary one, while the others are ignored (but still shown as content obviously). If a new tag is overkill for this, maybe doing it this way instead (using one of the new HTML5 tags): pheader summaryThis is just an example, it's a replacement for the old meta description, and is a brief summary (description) of the page (content)/header/p I really do not care how this is implemented/speced just as long as it's possible to do. I began thinking of this recently when it annoyed me that I basically had to enter the same content twice, after looking at my site links in Google, and thought to myself...Why do I have to use a meta description to tell Google to show the content in the first paragraph as the default summary of the page link? Why can't I simply specify that the first paragraph is the page's meta description? Why am I forced to bloat the page unnecessarily like this? Thee is no reason why the meta description can not be the actual content as in most cases I've seen the meta description is supposed to be fully human readable, unlike the meta keywords which no search engines bothers with at all any more. So if the meta description is supposed to be humanly readable and displayable as the page summary to humans in search results, why can't it also actually be in the page content? I can see at least two ways this will be used. The more elegant way I showed, where the first paragraph is a summary/the lead in of the page (and also happens to be the teaser content in my RSS feed as well), or at the bottom of a page with possibly linked category tags or similar within it, again allowing dual purpose and reduced redundancy. To re-iterate, the idea of the summary tag (or however it is implemented) should be to have a human readable summary (or teaser as may be) of a page, which is itself shown in the page, but also a replacement for search engines that use the old meta description avoiding redundancy. End result is (hopefully) less redundancy, and higher quality summary (page description) shown in search engine results, and so on. Also allowing people to quickly understand what a page is about by just reading the first paragraph (or be enticed to read more). Now if something like this allready exist/is possible I stand corrected and ask, please tell me how to do that. If not then I'd love to see something like this standardized. BTW! The text in the first paragraph of this very email could for example be the summary/description of this email. So if it was html tagged in some way, a mail indexing or search engine could use that as the summary or description view shown to a human user scrolling through archived emails. Regards, Roger. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Parsing processing instructions in HTML syntax: 10.2.4.44 Bogus comment state
On 3/2/2010 6:54 PM, Ian Hickson wrote: On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote: The handling of processing instructions in the XHTML syntax seems reasonably well-defined; but it feels a little off in the HTML syntax. There's no such thing as processing instructions in text/html. There was such a thing in HTML4, because of its SGML heritage, though it was explicitly deprecated. Doesn't seem deprecated per http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.6 Briefly it seems that? causes the parser to go into Bogus comment state, which is fair enough. (I wouldn't really recommend that anyone use processing instructions in HTML syntax anyway.) However the parser comes out of that state at the first. Because processing instructions can contain and terminate only at the two character sequence ? this could cause PI processing to terminate early and leave a lot more error handling and a confused parser state in the text yet to come. In HTML4, PIs ended at the first, not at ?. ?target data is the syntax of PIs when the SGML options used by HTML4 are applied. In any case, the parser in HTML5 is based on what browsers do, which is also to terminate at the first. It's unlikely that we can change that, given backwards-compatibility needs. There's a simple workaround: don't use PIs in text/html, since they don't exist in HTML5 at all, and don't send XML as text/html, since XML and HTML have different syntaxes and aren't compatible. In http://dev.w3.org/html5/html4-differences/ , it says: HTML5 defines an HTML syntax that is compatible with HTML4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML4, such as processing instructions http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.3.6 and shorthand markup http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.3.7. This seems to me to suggest that backward compatibility can be broken as far as processing instructions (i.e., requiring ? and not merely to close a processing instruction). If not, then it doesn't seem clear from the specification that processing instructions are indeed not allowed because the parsing model does allow them, and with processing instructions being platform-specific by definition and not apparently explicitly prohibited by HTML5 (unless that is what you are trying to say here), HTML5 syntax does seem to be compatible with them. But if you are trying to prohibit them for any use whatsoever yet still technically allow them to be ignored for compatibility, it seems this would contradict the statement at http://dev.w3.org/html5/html4-differences/ that there is no longer a need for marking features deprecated. Or is the difference that these are forbidden from doing anything but will be allowed (and ignored) indefinitely into the future in future versions of HTML? Btw, I've added a talk section at the wiki page http://wiki.whatwg.org/wiki/Talk:HTML_vs._XHTML#Harmony to suggest covering XHTML-HTML compatibility guidelines specifically, so would appreciate a reply there, so I know whether we can begin edits in this vein on the page. thanks, Brett
