- From: <bugzilla@jessica.w3.org>
- Date: Tue, 18 Oct 2011 02:32:06 +0000
- To: public-html-bugzilla@w3.org
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