Re: [whatwg] defer on style, depends
On Sun, 8 Feb 2009, Jonas Sicking wrote: This will allow browsers to not block on those elements. Browsers are already allowed to not block on those elements. Well, Garrett is somewhat correct. For example in the following scenario: link rel=stylesheet href=external.css script doStuff(); /script In gecko, when we parse the script tag, we'll block until all external stylesheets have finished loading before we start executing the script. This is because the script might be getting .offsetLeft or calling .getComputedStyle or some such, which uses style data. We have found that some sites break if we just use whatever style data happens to have loaded at that point, rather than ensuring that all stylesheets have been parsed and applied. Yes, external CSS can cause script elements to block on the CSS. However adding a 'defer' attribute to the style link seems like an odd fix as nothing is actually deferred. You very rarely actually want to defer stylesheet loading as you generally want to show content with stylesheets applied. Unstyled content tends to at best be ugly, at worst be totally nonsensical. A more logical fix would be to add an attribute to the script in question, indicating that the script can be executed without waiting for all stylesheets to load. Though that can be very painful to add to all scripts in the page. Possibly a page-wide attribute or API would better solve this problem. Though I'm not really a fan of either of those solutions either. I'm not convinced either of these are really great solutions. I think it'd be better just to have the script itself only block when it hits CSS-dependent APIs (though I recognise that that is a much harder problem in most rendering engines today). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] defer on style, depends
On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 8 Feb 2009, Garrett Smith wrote: Sometimes a document's resources are not needed all at first. For example, a script that is not needed until after the document is parsed can be given the defer attribute (for browsers that support defer). External css can also be a blocking download. Scripts have defer attribute, but style and link do not. The proposal is to add to defer to style, and link. This will allow browsers to not block on those elements. Browsers are already allowed to not block on those elements. But they do. If a script occurs after a link, the script expects updated style information. That is why browsers do block on scripts. http://dhtmlkitchen.com/jstest/block/link.html Includes a linked stylesheet that is delayed by 5 seconds. Results: contentLoaded: ~5101 onloadFired: ~5101 That result shows that I am correct on this matter. It would be more complete to have a depends attribute on script and style. script depends=a b c/script Where the depends is id-list [CS], space separated values of element IDs. Why can't you just put the script element below the elements whose IDs you would have listed? An associated script might need that stylesheet to be loaded before it runs. The depends attribute would guarantee that the stylesheet had loaded. The order should not change because the script is an inline scripts vs an external resource. A deferred stylesheet could be used to load a stylesheet after content was parsed. The developer would use defer when FOUC would be known not to occur as a result. For example, defer would be useful for an infoPanel widget that did not get shown until a certain event. The widget's HTML exists in the source code, towards the bottom, the script appears below that, just before the closing /body tag. There is a second problem: The problem of scripts being blocked by a stylesheet. The depends= attribute allows the script to declare that it needs style information first. This would be a much better design, and could probably be implemented by the browser with some nice event-driven code. Unfortunately, implementations that encounter link defer type=text/css..., followed by a script with no depends would still have to block on that stylesheet because that is what they do today. The script could declare itself as independent. That would result in links not blocking. To allow the stylesheet to load after all content loads, the stylesheet could declare defer: link defer src=deferred-all-min.css type=text/css rel=stylesheet id=lateBoundCSS To fulfill a requirement of having loaded of the stylesheet before the script runs, that script could declare depends to declare that it needs style information before loading. script defer depends=lateBoundCSS src=app-all-min.js/script It would also be useful to have a way to dynamically load scripts, other than createElement(script). This seems like a request for the ECMAScript group. Maybe. I would probably not be able to use it before I retire. It could also be a DOM document method. var script = document.createScript(src); script.load(); script.run(); script.unload(); A script belongs to a document. ECMAScript has no notion of document. Scripts loaded through this mechanism would ignore document.write. Applications could see a performance boost if developers could leverage such features. Garrett Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] defer on style, depends
On Mon, 9 Feb 2009, Garrett Smith wrote: On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 8 Feb 2009, Garrett Smith wrote: Sometimes a document's resources are not needed all at first. For example, a script that is not needed until after the document is parsed can be given the defer attribute (for browsers that support defer). External css can also be a blocking download. Scripts have defer attribute, but style and link do not. The proposal is to add to defer to style, and link. This will allow browsers to not block on those elements. Browsers are already allowed to not block on those elements. But they do. If a script occurs after a link, the script expects updated style information. That is why browsers do block on scripts. They block on scripts, yes. (Not on style.) See my reply to Jonas for further discussion of this matter. It would be more complete to have a depends attribute on script and style. script depends=a b c/script Where the depends is id-list [CS], space separated values of element IDs. Why can't you just put the script element below the elements whose IDs you would have listed? An associated script might need that stylesheet to be loaded before it runs. The depends attribute would guarantee that the stylesheet had loaded. The order should not change because the script is an inline scripts vs an external resource. It seems pretty simple to me; if you want the style to be loaded when the script runs, put the style first. If you don't, put the script first and defer it (or mark it async). Why should this not be enough? The depends= attribute allows the script to declare that it needs style information first. This would be a much better design, and could probably be implemented by the browser with some nice event-driven code. Unfortunately, implementations that encounter link defer type=text/css..., followed by a script with no depends would still have to block on that stylesheet because that is what they do today. The script could declare itself as independent. That would result in links not blocking. To allow the stylesheet to load after all content loads, the stylesheet could declare defer: link defer src=deferred-all-min.css type=text/css rel=stylesheet id=lateBoundCSS To fulfill a requirement of having loaded of the stylesheet before the script runs, that script could declare depends to declare that it needs style information before loading. script defer depends=lateBoundCSS src=app-all-min.js/script This seems like an inordinate amount of complexity for something that can just work already. It would also be useful to have a way to dynamically load scripts, other than createElement(script). This seems like a request for the ECMAScript group. Maybe. I would probably not be able to use it before I retire. We should not design specifications around the characteristics of the committees. If you have a problem with the ECMAScript group, I urge you to bring it to their attention. This forum is inappropriate for such discussion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] defer on style, depends
On Mon, Feb 9, 2009 at 9:23 AM, Ian Hickson wrote: I'm not convinced either of these are really great solutions. I think it'd be better just to have the script itself only block when it hits CSS-dependent APIs (though I recognise that that is a much harder problem in most rendering engines today). Dave Hyatt blogged about exactly this more than 2 years ago: http://webkit.org/blog/66/the-fouc-problem/ -- Thomas Broyer
Re: [whatwg] [html5] Rendering of interactive content
@Smylers:
So the whole rendering section is just for implementors and authors should
act if no default style sheet is present or worse, if it could be
everything, like a inline-block div or blue table, so that the author
should set all supported properties to initial or the HTML5 expected
value?
That is:
I, author, want consistent rendering on all plaforms and browser: I import
the HTML5 style sheet inside author ones.
I, implementor, want to provide backward-compatible rendering for those
author that didn't follow rule 1), I import HTML5 style sheet inside UA
defaults.
In both case, a downloadable stylesheet would be much appreciated.
@Benjamin:
1) Ian initially said that they chose the binding property (instead of
specifying appearance, border, color, etc.) in order to allow easy
resetting of default look-and-feel for widgets
2) I thought that author could make assumptions about the default CSS,
Smylers convinced me that this cannot be true
3) at least in that case I know that if web site doesn't work, it is not my
fault, but user's. But this has a major flaw:
customer is always right. In addition, once again, I was convinced that
you can't make assumption on UA rendering.
4)
input[type=text] {
border:1px solid blue;
font: Arial 10pt;
user-input: enabled;
user-modify: read-write;
cursor: url(I-beam.png);
}
looks different than
@appearance field {
border:1px solid ThreeDFace;
font:field;
user-input:enabled;
user-modify: read-write;
cursor: text;
}
@sys-color ThreeDFace rgb(0,0,255);
@sys-font field {
font-family: Arial;
font-size: 10pt;
}
@sys-cursor text {
src: url(I-beam.png);
}
input[type=text] {
appearance:field;
}
assuming three imaginary at-rules to define UA skin at CSS level.
5) I agree with you, it may be impossible
6) either HTML5 defines everything, or it defines nothing
Giovanni
Re: [whatwg] [html5] Rendering of interactive content
Giovanni Campagna writes: So the whole rendering section is just for implementors and authors should act if no default style sheet is present No; the section is also for authors, in that it advises them of how content is expected to be rendered in mainstream graphical browsers. or worse, if it could be everything, like a inline-block div or blue table, Indeed it _could_ be anything, but there's no reason for authors to be worried about that; if a (non-malicious) user-agent does something different from that expected by HTML 5 then it presumably has done so intentionally and it wouldn't necessarily benefit users for authors to attempt to combat it. so that the author should set all supported properties to initial or the HTML5 expected value? Not necessarily. That is: I, author, want consistent rendering on all plaforms and browser: I think that's where you're going wrong. Platforms themselves aren't consistent -- in things like screen sizes, resolutions, distance between screen and audience, whether they are interactive, what input devices are available, pagination. If an esoteric platform chooses to divert from the expected HTML 5 rendering then it's likely because that platform knows more about what rendering is appropriate for that platform that you do. I import the HTML5 style sheet inside author ones. That's a very parochial view. In mainstream graphical browsers such importing would be redundant, because they'll have the expected behaviour anyway. In esoteric user-agents you cannot know that the HTML 5 defaults provide a better user experience than those chosen by the user-agents' developers. I, implementor, want to provide backward-compatible rendering for those author that didn't follow rule 1), I import HTML5 style sheet inside UA defaults. In both case, a downloadable stylesheet would be much appreciated. I think a downloadable style-sheet is inevitable! Smylers
Re: [whatwg] [html5] Rendering of interactive content
2009/2/9 Smylers smyl...@stripey.com Giovanni Campagna writes: So the whole rendering section is just for implementors and authors should act if no default style sheet is present No; the section is also for authors, in that it advises them of how content is expected to be rendered in mainstream graphical browsers. or worse, if it could be everything, like a inline-block div or blue table, Indeed it _could_ be anything, but there's no reason for authors to be worried about that; if a (non-malicious) user-agent does something different from that expected by HTML 5 then it presumably has done so intentionally and it wouldn't necessarily benefit users for authors to attempt to combat it. The fact is that could lead to mixtures (part of UA stylesheets and part of author style sheets) caused by the cascade mechanism that cannot integrate themselves. so that the author should set all supported properties to initial or the HTML5 expected value? Not necessarily. That is: I, author, want consistent rendering on all plaforms and browser: I think that's where you're going wrong. Platforms themselves aren't consistent -- in things like screen sizes, resolutions, distance between screen and audience, whether they are interactive, what input devices are available, pagination. From the same CSS, you cannot get different results in different browsers or platforms (unless the browser are not complying with CSS). Content may be scaled, wrapped, clipped, overflowed, but it will always be the same. A mobile browser should be different than a resized Firefox window. (Actually, IE in Windows Mobile / CE is like IE in Windows XP / Vista, just with a smaller viewport. The same applies for Safari in the iPhone or in Mac OS). In addition, you can have digital pens also in desktop PC, but you expect that your browser renders in the same way. If an esoteric platform chooses to divert from the expected HTML 5 rendering then it's likely because that platform knows more about what rendering is appropriate for that platform that you do. I'm not sure the UA knows better than me how to render my web site, because this would mean it knows how to render every website in the whole world, better than its own author. It may know better than me how to render specific parts of it (ie widgets), but not all of it. I import the HTML5 style sheet inside author ones. That's a very parochial view. In mainstream graphical browsers such importing would be redundant, because they'll have the expected behaviour anyway. Can I assume they'll have the expected behaviour? No I cannot, because HTML5 explictly says that UAs may render in every way they like. In esoteric user-agents you cannot know that the HTML 5 defaults provide a better user experience than those chosen by the user-agents' developers. But I can know that it cannot provide a worse user experience, because, as I said, given a CSS and a media type (screen - interactive - visual), the rendering is always the same. Maybe scaled, wrapped, overflowed, but always the same. (yellow is still yellow, overflow: scroll still produces scrolling mechanisms, display:table renders a table, width:auto is like width:100% in non-floated non-positioned block-level elements, etc.) I, implementor, want to provide backward-compatible rendering for those author that didn't follow rule 1), I import HTML5 style sheet inside UA defaults. In both case, a downloadable stylesheet would be much appreciated. I think a downloadable style-sheet is inevitable! Then let's wait for Ian to write one. Smylers Giovanni
Re: [whatwg] defer on style, depends
Ian Hickson wrote: I'm not convinced either of these are really great solutions. I think it'd be better just to have the script itself only block when it hits CSS-dependent APIs (though I recognise that that is a much harder problem in most rendering engines today). I'm not sure how you envision this working. The run-to-completion semantics mean that while the script is working on the API call to return (which means that network events are being processed, etc), the following invariants need to be maintained (list very much not exhaustive): 1) No setTimeout timers fire. 2) No XMLHttpRequest state changes happen. 3) No image load events fire. 4) No stylesheet load events fire (for UAs that implement such an event on their link elements, as Gecko would like to do). 5) No user interaction with the page or other pages that can reach the given page is allowed. #5 makes it unlikely that a UA would want to go this route at all. #4 means that this approach would be incompatible with reasonable style load events... #1, #2, #3 all mean that networking needs to differentiate between the set of stylesheets we're waiting on and everything else. -Boris
Re: [whatwg] defer on style, depends
Jonas Sicking wrote: Well, Garrett is somewhat correct. For example in the following scenario: link rel=stylesheet href=external.css script doStuff(); /script In gecko, when we parse the script tag, we'll block until all external stylesheets have finished loading before we start executing the script. Strictly speaking, not quite. We'll block until all external stylesheets in the currently-selected style set have finished loading. Alternate stylesheets do not block script execution. So as of today, one can simple use alternate stylesheets for sheets that one does not need until end of pageload (though I fail to think of any cases where this would be desirable), then change the title/rel when desired. At least in Gecko, this will do what Garrett wants. -Boris
Re: [whatwg] defer on style, depends
On Mon, Feb 9, 2009 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Feb 2009, Garrett Smith wrote: On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 8 Feb 2009, Garrett Smith wrote: Sometimes a document's resources are not needed all at first. For example, a script that is not needed until after the document is parsed can be given the defer attribute (for browsers that support defer). External css can also be a blocking download. Scripts have defer attribute, but style and link do not. The proposal is to add to defer to style, and link. This will allow browsers to not block on those elements. Browsers are already allowed to not block on those elements. But they do. If a script occurs after a link, the script expects updated style information. That is why browsers do block on scripts. They block on scripts, yes. (Not on style.) See my reply to Jonas for further discussion of this matter. If I put the script at the bottom of the page, and a linked stylesheet in the head, the script waits for the stylesheet. I want my page to load faster and this feature prevents it. It would be more complete to have a depends attribute on script and style. script depends=a b c/script Where the depends is id-list [CS], space separated values of element IDs. Why can't you just put the script element below the elements whose IDs you would have listed? An associated script might need that stylesheet to be loaded before it runs. The depends attribute would guarantee that the stylesheet had loaded. The order should not change because the script is an inline scripts vs an external resource. It seems pretty simple to me; if you want the style to be loaded when the script runs, put the style first. If you don't, put the script first and defer it (or mark it async). Why should this not be enough? The implementation might delayed the page from rendering when it sees the stylesheet. The script's defer attribute does not work in a majority of implementations. For such browsers, it makes sense to put the script lower on the page for performance reasons, not before the linked stylesheets. Moving the deferred script from the bottom of the page to the head, just before the stylesheet would mean that those scripts would load first. This would prevent the page content from loading until those scripts had loaded. This would hurt performance in the majority of browsers in use today. Putting scripts at the bottom works in all browsers. Including a linked stylesheet in the head causes delays. Please see the link that Thomas Broyer provided. See the section Don't Stall. Please also visit the example I made last night. The depends= attribute allows the script to declare that it needs style information first. This would be a much better design, and could probably be implemented by the browser with some nice event-driven code. Unfortunately, implementations that encounter link defer type=text/css..., followed by a script with no depends would still have to block on that stylesheet because that is what they do today. The script could declare itself as independent. That would result in links not blocking. To allow the stylesheet to load after all content loads, the stylesheet could declare defer: link defer src=deferred-all-min.css type=text/css rel=stylesheet id=lateBoundCSS To fulfill a requirement of having loaded of the stylesheet before the script runs, that script could declare depends to declare that it needs style information before loading. script defer depends=lateBoundCSS src=app-all-min.js/script This seems like an inordinate amount of complexity for something that can just work already. Whatever. It would also be useful to have a way to dynamically load scripts, other than createElement(script). This seems like a request for the ECMAScript group. Maybe. I would probably not be able to use it before I retire. We should not design specifications around the characteristics of the committees. If you have a problem with the ECMAScript group, I urge you to bring it to their attention. This forum is inappropriate for such discussion. You focused on one sentence that I wrote. You misinterpreted what I wrote. I never ever suggested designing a specification around committee characteristics. I said: | A script belongs to a document. ECMAScript has no notion of document. Lets try to stay on-topic and focused. Thanks. Garrett
Re: [whatwg] defer on style, depends
Garrett Smith wrote: The script's defer attribute does not work in a majority of implementations. For such browsers, it makes sense to put the script lower on the page for performance reasons, not before the linked stylesheets. Moving the deferred script from the bottom of the page to the head, just before the stylesheet would mean that those scripts would load first. This would prevent the page content from loading until those scripts had loaded. This would hurt performance in the majority of browsers in use today. Putting scripts at the bottom works in all browsers. Including a linked stylesheet in the head causes delays. I'm not sure why you think that adding features to browsers to work around bugs in those same browsers is the right approach. Would just fixing defer for scripts fix your issue? Whatever. That's a very cogent and enlightening response, I'm sure, but it seems to be going over my head. Care to explain in terms someone of my limited mental ability can understand? -Boris
Re: [whatwg] defer on style, depends
On Mon, Feb 9, 2009 at 9:42 AM, Boris Zbarsky bzbar...@mit.edu wrote: Garrett Smith wrote: The script's defer attribute does not work in a majority of implementations. For such browsers, it makes sense to put the script lower on the page for performance reasons, not before the linked stylesheets. Moving the deferred script from the bottom of the page to the head, just before the stylesheet would mean that those scripts would load first. This would prevent the page content from loading until those scripts had loaded. This would hurt performance in the majority of browsers in use today. Putting scripts at the bottom works in all browsers. Including a linked stylesheet in the head causes delays. I'm not sure why you think that adding features to browsers to work around bugs in those same browsers is the right approach. Would just fixing defer for scripts fix your issue? There are two/three issues. 1) want to load stylesheets without having scripts block 2) want to load stylesheets later, (infoPanel example) 3) (2), but want to make sure the stylesheet is loaded before the script runs. (1) link independent .. would address the problem. There is no solution for (2) or (3). Current implementations may try to parse the script and see if it can run, but such algorithms are obviously not going to be effective. In the example, the document's title changes to bgColor=something. Adding defer to the script does not help. In fact, it makes the problem worse. What happens is that the deferred script waits for the link to load, but blocks content from loading. After the link loads, the script runs. Example 1: headtitle/title link independent type=text/css ... script.../script I want the browser to: 1) load my stylesheet and then immediately begin to load script in parallel. Example 2 headtitle/title link defer type=text/css id=lateBoundCSS ... /head body ... script depends=lateBoundCSS.../script /body I want the browser to: 1) defer my linked stylesheet id=lateBoundCSS until content is rendered 2) render content 3) upon encountering the deferred script, check the depends 4) upon finding Result(3) is lateBoundCSS, wait for that resource to finish load before running. The infoPanel script needs the infoPanel.css stylesheet, id=lateBoundCSS. The css is only related to that script, it is useless otherwise. The user might begin reading, use the search box, use the login box, or click links in the page. There is no reason why infoPanel.css needs to be loaded prior to the user doing those things. Whatever. That's a very cogent and enlightening response, I'm sure, but it seems to be going over my head. Care to explain in terms someone of my limited mental ability can understand? Boris, you have snipped what I replied to (the part Ian wrote before I wrote whatever). You replied to that out-of-context snip with a loaded question that seems very sarcastic. I do not think it such sarcasm is appropriate. I do not think it would be at all productive to answer such questions. Thanks. Garrett -Boris
Re: [whatwg] defer on style, depends
Garrett Smith wrote: There are two/three issues. 1) want to load stylesheets without having scripts block Already doable for alternate stylesheets, right? I assume the use case is a script that wants to modify the DOM immediately but doesn't depend on any styling information? That's a property of the script, not the stylesheet, correct? 2) want to load stylesheets later, (infoPanel example) Not sure what this example is, or why this is insufficienty served by, say, putting the link at the end of the HTML (assuming HTML allowed that, of course). 3) (2), but want to make sure the stylesheet is loaded before the script runs. (1) link independent .. would address the problem. Independent of what? In case (1) it's the script that doesn't depend on the stylesheet, as far as I can see. The stylesheet just exists. Example 1: headtitle/title link independent type=text/css ... script.../script I want the browser to: 1) load my stylesheet and then immediately begin to load script in parallel. That's exactly what Gecko does in this case, for what it's worth. It will load the script in parallel, but won't _execute_ the script until the non-alternate stylesheet has loaded. Example 2 headtitle/title link defer type=text/css id=lateBoundCSS ... What is the use case for such CSS, exactly? 1) defer my linked stylesheet id=lateBoundCSS until content is rendered 2) render content 3) upon encountering the deferred script, check the depends 4) upon finding Result(3) is lateBoundCSS, wait for that resource to finish load before running. Is this a common use case? Would it be sufficient to address it via a load handler on link so that one could build whatever dependency or ordering setup one wants? The infoPanel script needs the infoPanel.css stylesheet, id=lateBoundCSS. The css is only related to that script, it is useless otherwise. You mean the CSS is not actually used to style the document? Whatever. That's a very cogent and enlightening response, I'm sure, but it seems to be going over my head. Care to explain in terms someone of my limited mental ability can understand? Boris, you have snipped what I replied to (the part Ian wrote before I wrote whatever). Yes, because your response wasn't a response to what Ian wrote. I do happen to agree with Ian's opinion there, for what it's worth. Want to try convincing me that I'm wrong? Whatever is not convincing enough, sorry. You replied to that out-of-context snip with a loaded question that seems very sarcastic. I doesn't just seem. It _was_ sarcastic. I have to admit I was somewhat at a loss for how else one could respond to someone saying Whatever in response to a specific technical argument... I do not think it such sarcasm is appropriate. I do not think it would be at all productive to answer such questions. That depends on whether you want me to take your proposals seriously. If you do, you might want to take concerns raised about said proposals seriously. -Boris
[whatwg] Video playback quality metric
Measuring the rate at which the playback buffer is filling/emptying gives a fair indication of network goodput, but there does not appear to be a way to measure just how well the client is playing the video itself. If I have a wimpy machine behind a fat network connection, you may flood me with HD that I just can't play very well. The cpu or video card may just not be able to render the video well.Exposing a metric (eg: Dropped Frame count, rendered frame rate) would allow sites to dynamically adjust the video which is being sent to a client [eg: switch the url to a differently encoded file] and thereby optimize the playback experience. Anyone else think this would be good to have ? Thanks, Jeremy
Re: [whatwg] Video playback quality metric
On Tue, Feb 10, 2009 at 10:13 AM, Jeremy Doig jerem...@google.com wrote: Measuring the rate at which the playback buffer is filling/emptying gives a fair indication of network goodput, but there does not appear to be a way to measure just how well the client is playing the video itself. If I have a wimpy machine behind a fat network connection, you may flood me with HD that I just can't play very well. The cpu or video card may just not be able to render the video well. Exposing a metric (eg: Dropped Frame count, rendered frame rate) would allow sites to dynamically adjust the video which is being sent to a client [eg: switch the url to a differently encoded file] and thereby optimize the playback experience. Anyone else think this would be good to have ? Yes, I do. 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] defer on style, depends
On Mon, Feb 9, 2009 at 11:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Garrett Smith wrote:
There are two/three issues.
1) want to load stylesheets without having scripts block
Already doable for alternate stylesheets, right?
An html document could contain an alternate stylesheet, intended for a
script to change the stylesheet from alternate.
That would make the code less straightforward. It is going to be
harder for a fresh pair of eyes to understand what is going on.
I assume the use case is a script that wants to modify the DOM immediately
but doesn't depend on any styling information? That's a property of the
script, not the stylesheet, correct?
What do you propose?
A nodepends attribute for a script element?
Lets go over what I want the browser to do:
In general, I want better declarative control over loading external
resources. The solution(s) should not cause compatibility problems
with existing browsers (because I have to support IE6 and Firefox 2).
I want the browser to be able to load and run a script without being
in the position of trying to determine if it should wait for
stylesheet data to complete. I've noticed these things hang.
I also want to be able to load and run a script, without having to
resort to a clunky API (createElement('script')).
To declare the script to load and run immediately after the
stylesheets (without depending on the style information), Ian
suggested that I put the script first in the head and use defer.
That will have a negative affect on performance in all browsers that
support defer and the browsers that do not support defer.
In browsers that do not support defer, the scripts must be loaded
before subsequent content is loaded. The scripts will block content
from rendering below. Scripts will also prevent download of linked
stylesheets that appear after in the source. This type of design would
also have a negative effect on browsers that do *not* support defer
because it means that the scripts appear first, before any linked
stylesheets, and cannot be included at the bottom (which is common to
do for performance reasons).
In browsers that do support defer, the script would run *after* the
document parsed, and that would occur after the stylesheet loaded.
Example:
http://dhtmlkitchen.com/jstest/block/link-defer-top.html
We can see that the deferred alert external script will run first in
browsers that ignore defer. In browsers that do not ignore defer, it
will run last, after the stylesheet is loaded. Including a deferred
script first will result in an inconsistent execution of that script.
It would requires= a very flexible program design (that may result in
error if not very careful) and for absolutely no benefit.
The result would be bad for performance either way. This was Ian's
advice. It is impractical, error prone, and bad for performance. That
is horrible advice.
2) want to load stylesheets later, (infoPanel example)
Not sure what this example is, or why this is insufficienty served by, say,
putting the link at the end of the HTML (assuming HTML allowed that, of
course).
Are you proposing HTML allow that?
3) (2), but want to make sure the stylesheet is loaded before the script
runs.
(1) link independent .. would address the problem.
Independent of what? In case (1) it's the script that doesn't depend on the
stylesheet, as far as I can see. The stylesheet just exists.
The script could declare whether it needs such resource by its
depends= attribute. However, browsers today delay (some) scripts
from running. Scripts depend on stylesheets; content depends on
scripts and stylesheets. Content can contain more scripts. Omitting
depends for scripts could not possibly solve the problem for browsers
today (because they already depend on stylesheets).
An independent attribute on a link says that a browser does not need
to wait for that resource to finish loading before it loads other
resources (like loading a script). When the parser parses that
independent attribute, it sets a flag for the browser go ahead and
download and run any subsequent script.
A nodepends type attribute on a script would work, too. I like that
idea, though it does mean the browser has to do some lookahead (then
again, apparently they already do).
Example 1:
headtitle/title
link independent type=text/css ...
script.../script
I want the browser to:
1) load my stylesheet and then immediately begin to load script in
parallel.
That's exactly what Gecko does in this case, for what it's worth. It will
load the script in parallel, but won't _execute_ the script until the
non-alternate stylesheet has loaded.
For a script in the head, that is what Gecko and Webkit will do.
However, external resources such as SCRIPT or IMG that appear in the
BODY will not get requested by the browser until the page content
renders. That is actually a good argument for *not* moving scripts to
before the closing body tag.
In both cases (head script or body
Re: [whatwg] defer on style, depends
Garrett Smith wrote: In general, I want better declarative control over loading external resources. The solution(s) should not cause compatibility problems with existing browsers (because I have to support IE6 and Firefox 2). Honestly, by the time anything we're discussing now will be shipping in a browser Firefox 2 marketshare should be nonexistent. I can't speak for IE6. I want the browser to be able to load and run a script without being in the position of trying to determine if it should wait for stylesheet data to complete. As in you don't want the browser to make this determination, right? That is, you know that your script doesn't depend on any style data and you want the browser to just run it? I would be fine with a way to flag scripts with that information, though there is a catch-22: if you flag such a script and it DOES depend on style information, then existing UAs will get it right and any UA implementing the new spec will get it wrong. Of course the same is true for the flag-the-stylesheet proposal... In browsers that do support defer, the script would run *after* the document parsed, and that would occur after the stylesheet loaded. I'm not sure why this is a performance problem, per se. 2) want to load stylesheets later, (infoPanel example) Not sure what this example is, or why this is insufficienty served by, say, putting the link at the end of the HTML (assuming HTML allowed that, of course). Are you proposing HTML allow that? That's one possible solution to the issue of starting stylesheet loads as late as possible, yes. It's not a great one a priori, but has the benefit of good compat with existing UAs (which you said was a priority for you). The script could declare whether it needs such resource by its depends= attribute. However, browsers today delay (some) scripts from running. Scripts depend on stylesheets; content depends on scripts and stylesheets. Content can contain more scripts. Omitting depends for scripts could not possibly solve the problem for browsers today (because they already depend on stylesheets). Honestly, I don't think anything would solve the problem for browsers _today_. An independent attribute on a link says that a browser does not need to wait for that resource to finish loading before it loads other resources (like loading a script). When the parser parses that independent attribute, it sets a flag for the browser go ahead and download and run any subsequent script. That doesn't work for today's browsers, though, just like flagging the script doesn't. Or am I missing something? A nodepends type attribute on a script would work, too. I like that idea, though it does mean the browser has to do some lookahead (then again, apparently they already do). What sort of lookahead? Gecko, for example, just keeps parsing right past a stylesheet load. The only thing we stop the parser for is scripts, because those can do document.write. And even then, the speculative parser continues doing loads past that point. All that style sheets hold up is the script running, not the script loading (in Gecko). If the script were marked as doesn't have to wait for stylesheets, we could just run it as soon as it loads. That's exactly what Gecko does in this case, for what it's worth. It will load the script in parallel, but won't _execute_ the script until the non-alternate stylesheet has loaded. For a script in the head, that is what Gecko and Webkit will do. What I said was true for all scripts. We do not differentiate between content in head and content in body in this regard. However, external resources such as SCRIPT or IMG that appear in the BODY will not get requested by the browser until the page content renders. You mean until all the HTML before the tag has been parsed? Or something else? There's no dependency between script loading+execution and page rendering, in Gecko. Heck, you can run scripts in a display:none iframe, with no rendering in sight. In both cases (head script or body script), the browser will not execute the script until the stylesheet is downloaded. It won't render content that occurs after the script until the script is executed. That's correct, yes. So what we have here is a daisy chain. Content depends on Script depends on Style. That is very crude order of affairs and offers the developer little control over load order. Yes, agreed. to fulfill example 2, I would defer the stylesheet, and declare the script at the end depends on it. Before that script could run, the stylesheet would need to be loaded. Since the linked stylesheet is deferred, the body content would render and not be blocked by the linked stylesheet loading. Ah, that is one thing that Gecko does do: we don't start _layout_ (as opposed to parsing) until all the stylesheets in head have loaded. You can get around this trivially by putting a stylesheet as the first thing in body; that
