<link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Press+Start+2P" title="font" disabled> Marking the element as disabled in the document skips the download on the initial load (which makes sense). However, if we toggle the element later, the resource is not downloaded. To reproduce: http://jsbin.com/3/omulof/2/quiet It's interesting to note that enable/disable behavior *does work* for sub-resources. Ex: <link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Press+Start+2P" title="font"> <script type="text/javascript"> document.styleSheets.item('slow').disabled = true; </script> The above will result in the load of the stlylesheet, but the linked fonts will not be fetched. However, if we later toggle the stylesheet as enabled, then the sub-resources are loaded: http://jsbin.com/3/omulof/3/quiet --- Behavior we want: <link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Press+Start+2P" title="font" disabled> - Above should not be downloaded on page load. - If we toggle above stylesheet via JS later, the resource fetch should happen (plus its sub-resources.. @imports, url(), etc)
What does the spec tell us to do here?
(In reply to comment #1) > What does the spec tell us to do here? http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element "The IDL attribute disabled only applies to style sheet links. When the link element defines a style sheet link, then the disabled attribute behaves as defined for the alternative style sheets DOM... The rules for handling alternative style sheets are defined in the CSS object model specification. " http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction "For each xml-stylesheet processing instruction that is not part of the document type declaration and has an href pseudo-attribute these steps must (unless otherwise stated) be run: 1. Let title be the value of the title pseudo-attribute or the empty string if the title pseudo-attribute is not specified. 2. If there is an alternate pseudo-attribute whose value is a case-sensitive match for "yes" and title is the empty string terminate these steps." So, if I'm reading this correctly. No initial download is correct behavior. The problem is that there is no way to "enable" it later. And I don't see any specific language in the spec talking about the enable step either.
Thanks for looking that up. If it isn't clear about this, it is probably best to start a thread on whatwg first.
(In reply to comment #3) > Thanks for looking that up. If it isn't clear about this, it is probably best to start a thread on whatwg first. What's the question we're trying to get answered? This seems like an implementation edge case in WebKit: a resource can be marked as disabled, but there is no way to enable it later. After some further searching, a few sister bugs: #26673: Dynamically changing .disabled doesn't work #56932: Alternate stylesheets are not present in document.styleSheets crbug.com/88310: setting disable=true on stylesheet removes it from document.styleSheets To thicken the plot, unlike what the spec says above, WebKit does actually download alternate stylesheets today, which is inconsistent with behavior of "disabled" - and as the spec above shows, these are linked. Option (a): lazy load alternate and disabled stylesheets Option (b): load alternate and disabled stylesheets (both are implicitly disabled when loaded) P.S. Alternate download test: http://jsbin.com/3/omulof/15/quiet
There is no <link disabled> attribute in the spec! It shouldn't be supported. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element Comment 2 quotes spec text about the .disabled *IDL* attribute and the <?xml-stylesheet?> PI, neither of which apply in this case.
(In reply to comment #5) > There is no <link disabled> attribute in the spec! It shouldn't be supported. > > http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element > > Comment 2 quotes spec text about the .disabled *IDL* attribute and the <?xml-stylesheet?> PI, neither of which apply in this case. Hmm? It's right there in the IDL.. in the link your provided. interface HTMLLinkElement : HTMLElement { attribute boolean disabled; // first line } Also see: http://dev.w3.org/csswg/cssom/#the-stylesheet-interface
(In reply to comment #6) > Hmm? It's right there in the IDL.. in the link your provided. > > interface HTMLLinkElement : HTMLElement { > attribute boolean disabled; // first line Yes. But there's a difference between IDL attribute and content attribute. IDL attribute: <script>link_element.disabled = true;</script> content attribute: <link disabled="disabled"> The former exists in the spec, the latter does not. Comment 0 expects the latter to do something. > > Also see: http://dev.w3.org/csswg/cssom/#the-stylesheet-interface Also IDL attribute.
> Yes. But there's a difference between IDL attribute and content attribute. > > IDL attribute: > <script>link_element.disabled = true;</script> > content attribute: > <link disabled="disabled"> > > The former exists in the spec, the latter does not. Comment 0 expects the latter to do something. > > > > Also see: http://dev.w3.org/csswg/cssom/#the-stylesheet-interface > Also IDL attribute. Ah, that's a good catch.. :-) Hmm, in which case, should WebKit even be checking the disabled state in HTMLLinkElement::process(): http://trac.webkit.org/browser/trunk/Source/WebCore/html/HTMLLinkElement.cpp#L189 I guess as is, no harm done.. Except that it was that code that sent me down this path to begin with.
We are tracking WPT tests, and will address any CSSOM failures found there. I don't think we need to keep this 10 year old bug open.