Re: [whatwg] autobuffer on new Audio objects
On Mon, 20 Jul 2009 07:06:32 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Am Montag, den 20.07.2009, 05:46 +0100 schrieb David Wilson: It's easy to see how some naively implemented JS audio widget could fetch 200mb over an expensive 3G connection, simply by navigating to some site in a background tab (say, by creating an array of elements to represent their playlist - something I'd have thought was perfectly valid behaviour). I second that motion, not only as owner of a smartphone, but also as someone with webspace that has a volume cap. Automagic audio element buffering could deter web authors from dynamically putting more than one element on a page, thus reserving javascript playlist widgets to those who can afford more bandwith on an order of magnitude (!). I believe the burden of writing another line should solely be on those who want autobuffering, to prevent unneccessary bandwith consumption. Cheers Regardless of whether the spec mandates that the autobuffering attribute be set for new Audio(), browsers that want to be competitive on mobile will have to be conservative with bandwidth. autobuffering is only a hint and doesn't need to be obeyed where it doesn't make sense (in fact can't be obeyed because the disk cache is too small). -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] DOMTokenList feedback
On Mon, 6 Jul 2009, Sylvain Pasche wrote: I'm looking at the Gecko implementation of element.classList. I had a few comments about the spec. 1) http://html5.org/tools/web-apps-tracker?from=3253to=3254 missed something. There is still a mention of alphabetical sort order in the beginning of section 2.8.3: element = tokenlist . item(index) tokenlist[index] Returns the token with index index. The tokens are sorted alphabetically. Fixed. 2) contains/add/remove/toggle should mention what happens if an empty string token is passed in the token argument. Looking at the DOM Core exceptions, throwing a SYNTAX_ERROR seems to be the best match in this case (if we consider an empty string as invalid): SYNTAX_ERR, introduced in DOM Level 2. If an invalid or illegal string is specified. Done. 3) case sensitivity. Would be nice to address [1]. Note that the definition of uniqueness for .length and .item() will also need to be revisited if we want to handle classes in a case-insensitive way in quirks mode. [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020425.html I believe I replied to that e-mail a few days ago. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 20, 2009 at 4:46 PM, David Wilson d...@botanicus.net wrote:
It's easy to see how some naively implemented JS audio widget could
fetch 200mb over an expensive 3G connection, simply by navigating to
some site in a background tab (say, by creating an array of elements
to represent their playlist - something I'd have thought was perfectly
valid behaviour).
In your case even desktop Firefox is smarter than you think. We have a
tunable cache size which we won't download beyond until you free up space by
playing cached data. It's 50MB by default. On mobile we'd obviously reduce
that quite a bit.
I don't think your playlist example is compelling. DOM objects aren't good
for building playlists or other data structures. On the other hand,
var shotSound = new Audio(shot.wav);
...
function shoot() {
shotSound.play();
...
}
should work reliably. For small sounds, leaving out 'autobuffer' may not be
noticed on some browsers, since we have to download metadata and depending
on network conditions we often get the whole file before we start to
throttle the download for non-autobuffer elements.
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 20, 2009 at 5:06 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: I second that motion, not only as owner of a smartphone, but also as someone with webspace that has a volume cap. Automagic audio element buffering could deter web authors from dynamically putting more than one element on a page, thus reserving javascript playlist widgets to those who can afford more bandwith on an order of magnitude (!). document.createElement(audio) still creates a bare element. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] HTML5 Definition of week (section 2.4.5.6)
At 10:45 + 19/07/09, Ian Hickson wrote: On Fri, 3 Jul 2009, SJ Kissane wrote: I am concerned by the wording of this section. There are different systems of week number -- as far as I can work out, this is the same as ISO 8601 week numbering. But it nowhere explicitly says that. I think, the spec should have a normative reference to ISO 8601 for the definition of week numbering. Then, if the spec wants to give an informative recap of what ISO 8601 says, for the benefit of those who don't have a copy (especially since it isn't free), that's fine. But I'm worried, by inserting some complicated definition into the spec, does it match exactly ISO 8601's definition? (I'm sure it does, but are the definitions the same? is not immediately obvious from inspection.) They are not the same. ISO8601 doesn't define how you parse a week string, how you handle errors in such a string, and so forth. The numbers are compatible, and a valid HTML5 week string is an ISO8601 week string (though I don't know if the opposite is the case), but that's about it. While we could have an non-normative reference, in practice, it wouldn't add much, since (a) the HTML5 spec defines everything you might get from ISO8601, and (b) we don't want to have implementors think oh, it's the same as ISO8601, I'll just use an ISO8601 date library, since such a library might get the parsing details wrong in terms of what HTML5 says. an informative note to that effect might be a good idea. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- David Singer Multimedia Standards, Apple Inc.
[whatwg] W3C ACTION-132 Report on canvas accessibility
I have been requested to forward on the following important information regarding accessibility issues with the canvas element. If you have an interest in this area, or have some suggestions on how to overcome some of the known issues, then please consider actively following this W3C discussion, or better yet volunteer to be part of the Task Force. Thanks! JF * update on ACTION-132 Report on canvas accessibility[1] The Protocols and formats working group discussed the issues of canvas accessibility in their HTML caucus meeting last Friday (17/07/09). It has been decided to form a task force to work on specifying additions to the CANVAS API, that will result in canvas content being natively accessible. The task force is open to participation by any interested parties, the PF will host public bi-weekly teleconferences dedicated to the topic of canvas accessibility. The initial duration of the task force will be at least 3 months, but more likely 6 months, as I am sure that it is appreciated by all, the provision of a canvas API that could be considered to output accessible content is no simple undertaking. We have approached and are continuing to reach out to browsers vendors and other individuals and companies who can bring their expertise to bear on what is considered to be a critical accessibility issue in HTML5. The first meeting is expected to take place in the 1st or 2nd week of august, all discussion related to the canvas accessibility task force will be on the public html wg or wai-xtech lists. notification and agenda for the first teleconference will be published when the date has been confirmed. [1]http://www.w3.org/html/wg/tracker/actions/132 -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] Validation
Why is it okay for a document to not specify its HTML version? Do all browsers ignore it? How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? Should validators ignore older HTML version numbers which are listed in DOCTYPES? Why aren't MIME type version numbers included in HTTP Accept headers? Looks like it would be a valid HTTP/1.1 accept-extension: Accept: text/html; q=0.9; v=4.01, application/xhtml+xml; q=1; v=1.1, */*; q=0.1 I don't see anything about registering accept-extensions. -- Let's just say that if complete and utter chaos was lightning, then he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'. - The Color of Magic http://www.ChaosReigns.com
[whatwg] input type=tel validation, and a small set of typos
Two unrelated comments. First, it seems a bit odd to me that input type=email and input type=url are validated (for typeMismatch problems) but input type=tel isn't. I know it's prohibitively difficult to perfectly validate telephone number formats given the variety around the world, but it's also prohibitively difficult to validate email addresses per the relevant RFC, which is why HTML5 specs a much simpler algorithm that at least rejects obviously bad input. It seems like perhaps input type=tel could set typeMismatch if the input contained no numeric digits at all, or maybe if it contained characters outside 0-9, +, -, (, ), ' ', ...? Maybe the level of validation provided by these proposals is so low that it's not worth doing, though. Second comment: There are 4 instances of a small typo in attribute lists, where ..., required, size, ... is rendered as ..., required size, See the bookkeeping details portions of sections 4.10.4.1.19, 4.10.4.1.20, 4.10.4.1.21, and 4.10.4.1.22. PK
Re: [whatwg] Validation
Am Montag, den 20.07.2009, 15:01 -0400 schrieb dar...@chaosreigns.com: Why is it okay for a document to not specify its HTML version? Because HTML 5 is designed with upwards-compatibility in mind. HTML 6 browsers should read HTML 5 documents just fine. Do all browsers ignore it? All modern browsers skip into standards mode on encountering !DOCTYPE html. How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? I assume the validator will probably check for a current version of HTML. Most of the older versions of HTML are subsets of current versions. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] input type=tel validation, and a small set of typos
Am Montag, den 20.07.2009, 12:47 -0700 schrieb Peter Kasting: It seems like perhaps input type=tel could set typeMismatch if the input contained no numeric digits at all, or maybe if it contained characters outside 0-9, +, -, (, ), ' ', ...? Maybe the level of validation provided by these proposals is so low that it's not worth doing, though. What's with alphanumeric notation ? I think of 555-WHATWG as a possibly valid telephone number. It might be good to have an RFC on that. Or maybe ITU has publicly available documents on numbering plans ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] input type=tel validation, and a small set of typos
On Mon, Jul 20, 2009 at 12:56 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: What's with alphanumeric notation ? I think of 555-WHATWG as a possibly valid telephone number. It might be good to have an RFC on that. Or maybe ITU has publicly available documents on numbering plans ? Yeah, I thought of that kind of thing (but didn't mention it). If we don't want to disallow users from doing things like this, there probably isn't a simple enough validation algorithm we can use. It might be nice to mention in the spec why type=tel is not validated the way email and url are, at that point. PK
Re: [whatwg] input type=tel validation, and a small set of typos
On Mon, Jul 20, 2009 at 2:47 PM, Peter Kastingpkast...@google.com wrote: Two unrelated comments. First, it seems a bit odd to me that input type=email and input type=url are validated (for typeMismatch problems) but input type=tel isn't. I know it's prohibitively difficult to perfectly validate telephone number formats given the variety around the world, but it's also prohibitively difficult to validate email addresses per the relevant RFC, which is why HTML5 specs a much simpler algorithm that at least rejects obviously bad input. It seems like perhaps input type=tel could set typeMismatch if the input contained no numeric digits at all, or maybe if it contained characters outside 0-9, +, -, (, ), ' ', ...? Maybe the level of validation provided by these proposals is so low that it's not worth doing, though. You got it. While emails officially have a very complex format, in practice they follow a fairly simple, restricted format that can be usefully validated. Telephone numbers, on the other hand, differ wildly across the globs, and you can't just identify a restricted subset that 'most' fall into. Even if you could identify a sane subset of validation that you could apply widely, it would be weak enough to be worth basically nil in terms of actually ensuring that you've received a valid telephone number. ~TJ
Re: [whatwg] Validation
On 07/20, Nils Dagsson Moskopp wrote: How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? I assume the validator will probably check for a current version of HTML. Most of the older versions of HTML are subsets of current versions. Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. And I want to use a spidering validator on my entire site. And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. It seems to me that in this case having an HTML version number somewhere in the document would be useful. And that this is a practical example. -- No human thing is of serious importance. - Plato http://www.ChaosReigns.com
Re: [whatwg] Validation
Am Montag, den 20.07.2009, 16:12 -0400 schrieb dar...@chaosreigns.com: Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. Uh-okay. What could various means be ? And I want to use a spidering validator on my entire site.And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7 validator could check all pages and report those that aren't valid HTML 7. Those pages could then put onto a list that is checked by the HTML 9 validator. It seems to me that in this case having an HTML version number somewhere in the document would be useful. And that this is a practical example. See the above question. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Validation
On 07/20, Nils Dagsson Moskopp wrote: Uh-okay. What could various means be ? Something like: object src=image.svg img src=image.png /object Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7 validator could check all pages and report those that aren't valid HTML 7. Those pages could then put onto a list that is checked by the HTML 9 validator. Because I don't want to have to tell the validator which pages are HTML7 and which pages are HTML9, I want it to figure it out automatically. -- in the grim future of hello kitty there is only war - http://onastick.net/sitz/images/ http://www.ChaosReigns.com
[whatwg] DOMTokenList and whitespace
Hi, 1) What's the reason for preserving whitespace when a DOMTokenList method is changing the attribute? 2) If preserving whitespace is not important, what about normalizing whitespace during mutation? By normalizing whitespace, I mean splitting tokens (keeping unique ones), doing the DOMTokenList add/remove/toggle operation, and joining tokens together separated by a whitespace. I've already implemented the current spec algorithm in Mozilla [1], but normalizing whitespace should simplify things a bit. It would be interesting to have other implementor's opinion on this. (Note: this was previously raised in [2], but it should have been a new thread.) Sylvain [1] https://bugzilla.mozilla.org/show_bug.cgi?id=501257 [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021018.html
Re: [whatwg] Validation
On Mon, Jul 20, 2009 at 10:27 PM, dar...@chaosreigns.com wrote: On 07/20, Nils Dagsson Moskopp wrote: Uh-okay. What could various means be ? Something like: object src=image.svg img src=image.png /object Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7 validator could check all pages and report those that aren't valid HTML 7. Those pages could then put onto a list that is checked by the HTML 9 validator. Because I don't want to have to tell the validator which pages are HTML7 and which pages are HTML9, I want it to figure it out automatically. You don't have to tell the validator which version is each page. All the previous knowledge included in the setup Nils posted would be some pages are HTML7, and some are HTML9; then you just feed/send/pipe/whatever all pages to the HTML7 validator: since HTML9 would be a superset of 7, everything that passes this validation is valid as both HTML7 and HTML9. Then, based on the result, failed pages would be sent to the HTML9 validator: if they pass, they are HTML9 with features not included in 7; otherwise they are just invalid. Although it may depend from the specifics of the validation software used, automating this sequence would be easy on the general case, and trivial on the best scenario. Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... The same is true for any other browser sequence: Firefox3 handles all pages that Firefox2 did; and the later included all those pages that rendered properly in FF1. More on the same with Opera, Safari, Konkeror, and so on (Chrome isn't too relevant here because it's quite young). The only problem could happen if, for example, I (or someone else) built a new browser, only with HTML5 on mind, when trying to open an HTML4 (or earlier) page; but the HTML5 spec already addresses this: to be compliant a browser must treat any valid input in a well-defined way; but it also must treat invalid input in a well-defined way; which is actually defined to make HTML5-compliant browsers render old and invalid content quite like current browsers do. Thus, if after HTML5 some features are deprecated (just like font has been removed from the HTML specs), there will be pages using those features that will not be valid HTML6, but HTML6 will still define exactly what browsers are expected to do with them. It seems that you worry about validation. Actually, there is some reason to worry: many HTML4 Transitional pages (namely, those that use font or other obsolete aberrations) will be reported as invalid when processed by an HTML5 (or later) validator. So you should actually worry about this; but not complain, because it is the best thing a validator can do, warning you that you are using something (like font) that you shouldn't be using. Now, don't try to argue using font (or some other obsolete tag) should be Ok, because it's valid on HTML4: on HTML4 these things are already *deprecated*. Every time you see that word on the HTML4 spec, read it as an apologize from W3C, just like saying we should have never added this to HTML; now we regret it and it shouldn't be used. Of course, a lot of legacy content will no longer validate with HTML5 validators; but where is the issue? It will still render. After all, no one would expect Don Quixote or Hamlet to be valid according to modern Spanish and English rules, respectivelly, but people who know either language are still able to read them. This is an inherent part of language evolution; and hence is a needed side-effect for evolving HTML. And we need to evolve HTML, becuase the current standard is over a decade old, and is falling short to the web's needs every now and then. Just my PoV anyway. Regards, Eduard Pascual
Re: [whatwg] Validation
On 07/20, Eduard Pascual wrote: feed/send/pipe/whatever all pages to the HTML7 validator: since HTML9 would be a superset of 7 You didn't mean that, did you? Oh, HTML9 would specify a superset of what browsers are required to handle gracefully, not actually including everything from 7 in 9. , everything that passes this validation is valid as both HTML7 and HTML9. Then, based on the result, failed pages I think you mis-stated, but it doesn't not detract from the validity of your suggested method. would be sent to the HTML9 validator: if they pass, they are HTML9 This still leaves me to manually verify that all pages that I wanted to validate as 7, did. Now, don't try to argue using font (or some other obsolete tag) should be Ok, because it's valid on HTML4: on HTML4 these things are I would never. -- When in doubt, gas it. It may not solve the problem, But it ends the suspense. - Steve Moonitz, DoD #2319, 1994 http://www.ChaosReigns.com
Re: [whatwg] Validation
W liście Eduard Pascual z dnia poniedziałek 20 lipca 2009: Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... That would be nice if it was true. Have you seen the list of pages compatible with IE6 but not IE8 (eg here: http://blogs.zdnet.com/microsoft/?p=2072tag=nl.e539)? -- Paweł Stradomski
[whatwg] In AppCache web apps, images from unpredictable domains won't load
On Mon, 6 Jul 2009, Aaron Whyte wrote: When a page is loaded from an AppCache, even when online, external resources such as images will not be loaded at all. If foo.com has an image img src=http://bar.com/img.png; /, then according to the steps in http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel it will fail the load for the resource. Right; an app is intended to be self-contained, such that if it uses a manifest, and has been tested and shown to work (even while online), it is more or less guaranteed that it will work offline. For example, someone with an Offline Gmail client would never be able to see cross-domain images in emails, even when completely online. Good point, an app that shows uncached externally-sourced content is going to have trouble with the closed-sandbox model. On Mon, 6 Jul 2009, Aaron Boodman wrote: I think we could fix this issue by simply changing the rules to default to allowing requests, and having the author mark the url prefixes he wants to blacklist from being loaded from the network. On Mon, 6 Jul 2009, Michael Nordman wrote: That would work too. We'd have to introduce a new kind of 'namespace' in the manifest file. I've made it so that you can specify * in the online whitelist section to basically open it up to anything. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Validation
On Mon, Jul 20, 2009 at 8:12 PM, dar...@chaosreigns.com wrote: Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. And I want to use a spidering validator on my entire site. And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. So have the validator say This is valid HTML7 or This is valid HTML9 or This is valid HTML7, HTML8, and HTML9 or whatever is applicable. It can check all the standards at once. Why does it need to check only one? If there are practical issues, of course, a later version of HTML could always mandate a different doctype, and validators would know that !doctype html means HTML 5, while !doctype html6 means HTML 6, or whatever. But this doesn't seem necessary or useful.
Re: [whatwg] Fragments included in Application Cache master entries
On Mon, 6 Jul 2009, Andrew Grieve wrote: The current behavior in Webkit is for URL fragments to be stored in the URLs for master entries. I believe this to be a bug in Webkit, but cannot determine from the spec if this is or not. It was also a spec bug. I've fixed it in the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Audio synthesis
On Mon, 6 Jul 2009, Charles Pritchard wrote: Use a sound of varying pitch to hint to a user the location of their mouse (is it hovering over a button, is it x/y pixels away from the edge of the screen, how close is it to the center). Alter the pitch of a sound to make a very cheap midi instrument. Pre-mix a few generated sounds, because the client processor is slow. Alter the pitch of an actual audio recording, and pre-mix it, to give different sounding voices to pre-recorded readings of a single text. As has been tried for male female sound fonts. Support very simple audio codecs, and programmable synthesizers. Cool, thanks, I've noted these in the spec's source. I think some of these would indeed justify adding an API in the next versions of the language. On Tue, 7 Jul 2009, Philip Jagenstedt wrote: For all of the simpler use cases you can already generate sounds yourself with a data uri. For example, with is 2 samples of silence: data:audio/wav;base64,UklGRigAAABXQVZFZm10IBABAAEARKwAAIhYAQACABAAZGF0YQQA. It might be worthwhile implementing the API you want as a JavaScript library and see if you can actually do useful things with it. If the use cases are compelling and require native browser support to be performant enough, perhaps it could go into a future version of HTML. A JS library attempting to do this would definitely be helpful in determining how much need there is for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Tue, 7 Jul 2009, Jonas Sicking wrote: What's tricky is that a document.write inside a deferred script in IE will in some circumstances clear the current document, in other cases append to it. Specifically it seems that if the page has ever set .innerHTML on any node then document.write in the deferred script will append to the current page. If .innerHTML has never been set, then it will replace the current page. Actually what's going on is more subtle than that. When you set innerHTML, it's actually triggering the deferred scripts right there, if it has them loaded (e.g. inline scripts or cached scripts). If it doesn't have them loaded yet, it drops them on the floor and doesn't ever run them. I've specced this, except that the spec requires that not-yet-loaded scripts be loaded then run, rather than dropped, before innerHTML continues, so there's no race conditions. [...] So all in all, I'd like to see the following changes to the spec: * While executing deferred scripts, let the insertion point be at the end of the document. I've specced the actual IE behaviour with innerHTML instead. * Don't fire DOMContentLoaded until all deferred scripts have executed. * Possibly hold off firing DOMContentLoaded until any outstanding scripts have finished loading and executing. I've done this. In fact, I've made it wait until all scripts that were pending when the parsing finished have been run. (You mentioned .readyState; I haven't changed that, since it makes the 'interactive' state far less useful if it only gets set once all the scripts have run but before the images have loaded. Being able to detect when or whether parsing has finished while running deferred scripts does seem useful. Hopefully it's not too much rope.) * Always execute elements in the order they are inserted into the Document, with exception of async and deferred scripts. I haven't done this, because people use document.appendChild() of external scripts specifically to have scripts run ASAP and not necessarily in order. In general, I am very wary of changing this part of the spec, as it was written with extreme care based on all the tests I could run, primarily on IE, but also on other browsers. The innerHTML thing, though... I'll admit I really didn't even remotely think that there could be something to test! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
Ian Hickson wrote: Actually what's going on is more subtle than that. When you set innerHTML, it's actually triggering the deferred scripts right there, if it has them loaded (e.g. inline scripts or cached scripts). If it doesn't have them loaded yet, it drops them on the floor and doesn't ever run them. I've specced this, except that the spec requires that not-yet-loaded scripts be loaded then run, rather than dropped, before innerHTML continues, so there's no race conditions. Er... wait. So innerHTML has to block on network access? And possibly spin the event loop as it does so? This doesn't seem desirable to me Why do we want this behavior? -Boris
Re: [whatwg] Validation
Am Montag, den 20.07.2009, 23:54 +0200 schrieb Paweł Stradomski: W liście Eduard Pascual z dnia poniedziałek 20 lipca 2009: Browsers are built incrementally. For example, IE10 is very likely to render properly any page that IE9 had rendered properly (plus some that IE9 couldn't handle). And IE9 will handle any page that IE8 handles (plus some that are too much for IE8), just like IE8 handles any page that IE7 (in addition to those that use CSS2 features not supported by IE7), and IE7 renders all the stuff that IE6 renders, and so on... That would be nice if it was true. Have you seen the list of pages compatible with IE6 but not IE8 (eg here: http://blogs.zdnet.com/microsoft/?p=2072tag=nl.e539)? Caveat: This seems to be an IE issue, not an HTML issue. Why ? I checked the top 8 and bottom 4 sites on that list using the W3C validator and not a single one would validate. Quite a few generate hundreds of errors and warnings. Moral of the story ? Relying on quirks of a specific implementation is a bad idea. To turn that into a HTML needs version numbers (to accomodate exactly this behaviour) is more than a stretch. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Validation
On Tue, Jul 21, 2009 at 2:43 AM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Caveat: This seems to be an IE issue, not an HTML issue. Why ? I checked the top 8 and bottom 4 sites on that list using the W3C validator and not a single one would validate. Quite a few generate hundreds of errors and warnings. The biggest IE6 compatibility problems lie in CSS, not HTML. Authors writing code for IE6 have to willfully violate the CSS standard to get it to display correctly, e.g., because of IE6's completely broken box model. Adhering to standards doesn't help if some browsers you need to support ignore the standards. It's irrelevant to the proposal under discussion in any event. Separate doctypes would do nothing to help here.
[whatwg] Driveby typo notice
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource When the user agent has completely fetched of the entire media resource s/ of//
