[Bug 13977] Check browsers; it might be that links with rel=stylesheet that aren't yet loaded should still have a sheet. See also https://bugs.webkit.org/show_bug.cgi?id=65140

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13977

--- Comment #5 from Boris Zbarsky <bzbarsky@mit.edu> 2011-10-18 02:32:05 UTC ---
(In reply to comment #2)
> In Gecko, <link> loading blocks parsing.

No, it does not.

It blocks execution of <script> elements, however.

> For rel=stylesheet, a .sheet object is
> created as soon as the element is created.

That's correct.

> For other links, e.g. rel="alternate stylesheet" or rel=nothing, .sheet is
> null.

"alternate stylesheet" (or indeed any rel value containing "stylesheet" of
type="text/css" or no type set) should behave just like rel="stylesheet" in
Gecko.  What testcase did you use to determine the above?

Gecko's behavior is basically like this:  Insertion of a <link> (if it's
determined to be a CSS stylesheet link via @rel and @type) or <style> element
in the DOM immediately creates the .sheet and puts it in the right place in
document.styleSheets.  Similar for a mutation to @rel or @type that makes a
previously-not-CSS link into a CSS link.

> In WebKit, .sheet is null until the sheet is loaded.

How is "loaded" defined?  If the sheet has @import rules, do those need to be
loaded too?  (Think esp. for <style>.)

> I think Gecko's idea makes sense and solves the problems raised around this,
> but why not have a sheet for rel="alternate stylesheet"? (bz?)

We have a sheet for rel="alternate stylesheet" right after insertion into the
DOM as far as I know, per above.  Just double-checked with a simple testcase,
and it's there...

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 18 October 2011 02:32:12 UTC