[whatwg] Link.onload; defer on style, depends
ian at hixie.ch
Tue Mar 24 19:24:46 PDT 2009
On Fri, 13 Feb 2009, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > By the way, the spec doesn't yet require the blocking behavior. I
> > couldn't work out how to do it. Could you elaborate on when exactly in
> > the process the style sheet is waited on? Does it happen for all
> > scripts? For example, if a script inserts a style sheet and then a
> > script, does that script wait for the style sheet to load?
> The current Gecko behavior is that any stylesheet load started by
> parsing a <style> or <link> tag will increment a counter on the document
> (well, on a per-document script loader object, to be more precise).
> Completion of the load will decrement the counter. While the counter is
> nonzero, <script> execution is blocked. When it goes back to 0, the
> first pending script (if any) is run. If this increments the counter
> again, no more scripts are run until the count goes to 0 again.
> So it doesn't matter how the script is created/inserted, but the only
> stylesheets that block scripts are ones that the parser knows about.
> So only the ones present in the original source or added via
> document.write. If you createElement a <link> and insert it into the
> DOM, it won't block script execution. Also, <link> elements pointing to
> alternate style sheets don't block script execution.
So testing this:
(44 uses currentStyle, for IE/Opera, 45 uses getComputedStyle, for Opera/
It seems Gecko is the only engine that blocks here.
It would be interesting to hear from other browser vendors about their
opinions on this issue.
On Sun, 15 Feb 2009, Boris Zbarsky wrote:
> > So in this:
> > <!DOCTYPE html>
> > ...
> > <script>
> > document.write('<link rel=stylesheet href=style>');
> > document.write('<script>a();<\/script>');
> > b();
> > </script>
> > ...is the script paused after the second document.write() call, before a()
> > and b() execute?
> No. What's paused is execution of new scripts, not of existing ones. So in
> this case, b() executes immediately, while a() executes after the stylesheet
Woah, so this can affect the order of script execution?
That seems very dangerous. What if b() depends on a()? I would be
surprised if this didn't cause compatibility problems.
On Sat, 14 Feb 2009, Garrett Smith wrote:
> > Garrett:
> > >
> > > What would make it easier? I'd really like to know how to design my
> > > pages so that they are faster and more responsive.
> > Well, one option is to stop worrying about micromanaging the load
> > order and assume that speculative parsing will solve your problems....
> > will it?
> Possibly. If the author could declare what a script depends on and let
> the implementation determine what to load and when, would that be too
It seems like this is in general an issue that would be best left up to
the browsers to optimise for, instead of having authors be able to
micromange this (as Boris put it).
In general, scripts shouldn't depend on style sheets anyway; if you are
writing code where you want things to be fast, just avoid breaking that
rule of thumb and then it will never matter.
On Sun, 15 Feb 2009, Garrett Smith wrote:
> Ian wrote:
> > On Mon, 9 Feb 2009, Garrett Smith wrote:
> > >
> > > There are two/three issues.
> > > 1) want to load stylesheets without having scripts block
> > Put the scripts first.
> Then the scripts block. I explained this and showed this in examples.
> If the script is deferred, it will wait for the stylesheet.
For the case where you just want scripts to load whenever they are ready
to load, you can use async="".
> >> 2) want to load stylesheets later, (infoPanel example)
> > Put the styles later.
> The script blocks the stylesheet.
The alternative is to just let the browser manage this and load the style
sheets whenever they want.
> >> 3) (2), but want to make sure the stylesheet is loaded before the
> >> script runs.
> > Put the styles first.
> The stylesheet can be placed right before the script which depends on
> it, right before closing body tag:
> and the result will "work" in Firefox. However, that does not works
> consistently in a wide enough range of current browsers. Particularly,
> Webkit and Opera will alert('loaded') before getting the stylesheet.
Make the script not depend on the style sheet then.
In general, I don't think that this feature request is something that
really is necessary on the Web. The best way forward is really to just
design your scripts such that they don't depend on the style sheets (you
have no guarantee that the user will get the CSS anyway), and then to just
rely on the browser vendors to make the right decisions about when to
fetch each file.
On Sat, 14 Mar 2009, Greg Houston wrote:
> This is a request for the link element to be given an onload attribute.
> Often when lazy loading a plugin into an web app it is necessary for the
> downloaded. Without the link element having an onload event there is not
> really a straightforward way of doing this.
In general I would recommend against having scripts that depend on
On Sat, 14 Mar 2009, Greg Houston wrote:
> On a side note, I can actually attach a functioning onload event to a
> link element in Internet Explorer. Firefox, Safari, and Chrome ignore
> my attempt, and Opera will fire the onload event but not update the
> style of the page.
Since there are already implementations of this I've gone ahead and
On Sun, 15 Mar 2009, Jonas Sicking wrote:
> A web application, such as GMail, wanting to show a dialog box to the
> user asking the user to enter some information. In order to do this it
> needs to first load a stylesheet to properly style the dialog box. The
> application would do this by inserting a <link rel="stylesheet"
> href="dialog.css"> into the head of the document. It would then want to
> know when the stylesheet has loaded so that it can display the dialog
I think long-term our best course of action for this use case is actually
to have an explicit element that can be used to display dialog boxes, for
what it's worth.
On Sun, 15 Mar 2009, Boris Zbarsky wrote:
> Sean Hogan wrote:
> > > This is a request for the link element to be given an onload
> > > attribute.
> > And presumably a readyState property.
> At least in Gecko, you can already detect whether the sheet is done
> loading: if you try to get its cssRules and that throws
> INVALID_ACCESS_ERR, then it's still loading. (If it throws
> DOM_SECURITY_ERR then you're not allowed to read the style data; that's
> why you have to check for the exact type of exception thrown. Though
> really, if you're loading style sheets cross-site you're in for a world
> of hurt unless you control both sites.)
I haven't added readyState at this time. I am concerned about feature
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg