Need to specify <style> only works on browsing-context-having documents

[domenic]

Quick test case: https://jsbin.com/cozenirite/1/edit?html,css,console,output shows the computed style of the p is not changed, and (if you check the network panel) the @import is not fetched.

A quick fix may be to add a check to step 3 of https://html.spec.whatwg.org/multipage/semantics.html#update-a-style-block that the node document has a browsing context.

We probably also want to update the conditions under which it runs (a paragraph before) to use BC-connected/BC-disconnected instead of just connected/disconnected.

[annevk]

We went over this during the Web Components F2F and as I recalled we had pretty explicitly decided on the current model I looked into that and it turns out user agents do create style sheets today. They might not fetch subresources and they might not contribute to resolved styles, but <style>.sheet is non-null.

[rniwa]

I think the style sheet object is created by the style is never applied and it's never added to document's stylesheet or something like that.

[erickzhao]

PR #1137 explicitly removed a clause that specified that the style block update algorithm should only work on "element[s] whose node document has a browsing context". Seems like this used to be explicit and was intentionally removed?

I'm coming from discussion on chromium#437153, where the pre-1137 wording caused Chromium to have a misalignment with the spec (see demo here).

[domenic]

Right, it was intentionally removed per @annevk's comments above, that .sheet exists for such cases.

However, the test case you found (with XHR responseDocs) is interesting, because Firefox gives it a null .sheet and Chrome gives it a CSSStyleSheet object. I guess document.implementation.createHTMLDocument() and XHR responseDocs are treated differently by Firefox.

[annevk]

We should probably also test DOMParser() and createContextualFragment() (with various different documents) then.

Edit: per @hsivonen Firefox has a "data document" concept that's used for XMLHttpRequest and DOMParser. I'm not sure if other browsers have that concept though and it doesn't seem great that new Document() wouldn't create that. Doing what OP suggests seems much more reasonable to me now, but I'm not sure how web compatible that is.

[erickzhao]

@annevk I haven't contributed to any web standards stuff before, but would be happy to attempt to add a Web Platform Test for the various test cases mentioned in issue!

[annevk]

That sounds great and will help determine where browsers are at and with making changes, if any.