Shadow DOM, <style>, and document.styleSheets

[hayatoito]

Title: [Shadow]: Style element should specify when to create and add style sheet in shadow DOM (bugzilla: 26850)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26850

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26850#c0
William Chen wrote on 2014-09-18 18:32:10 +0000.

The spec currently specifies the ShadowRoot styleSheets property as:

"On getting, the attribute must return a StyleSheetList sequence containing the shadow root style sheets."

The spec for the style element only specifies creating sheets for elements "in a Document":

https://html.spec.whatwg.org/multipage/semantics.html#update-a-style-block

The spec for "create a CSS style sheet" only adds sheets to the document:

http://dev.w3.org/csswg/cssom/#create-a-css-style-sheet

As it's currently specified, .styleSheets always returns an empty list.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26850#c1
Simon Pieters wrote on 2014-09-19 11:15:21 +0000.

HTML and/or CSSOM can probably be changed if needed.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26850#c2
Ian 'Hixie' Hickson wrote on 2014-09-26 18:27:21 +0000.

Yeah. Tell us what needs changing.

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26850#c3
Kenji Baheux wrote on 2014-12-04 07:45:01 +0000.

Hayato: let me increase the priority since we probably need to resolve this one to move forward on 27418

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26850#c4
Hayato Ito wrote on 2014-12-04 07:50:42 +0000.

I think this is yet another instance of 'In a Document' issue.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365.

[TakayoshiKochi]

In
https://github.com/w3c/web-platform-tests/blob/master/shadow-dom/ShadowRoot-interface.html
testStyleSheets() hits this issue.

The test creates a <div> and attaches a shadow on it, then appends some <style>s
in the shadow, and checks styleSheets.length.
In the test, the shadow host <div> is never attached to anything, so these <style>s are not
connected to the document, thus the styleSheets.length could be 0, but the test expects 2.

(For here, let's assume "in a Document" in the discussion above means the shadow host is
appended to somewhere traversible from the document root.)

Clarification needed when style sheets are added to ShadowRoot,

1. at <style> is attached in a 'ShadowRoot''s tree (the wpt test assumes this)
2. at its attached ShadowRoot is attached in the document tree

2 makes sense in that the timing is <style> is effectively applied (i.e. affects actual rendering).

[rniwa]

I'm no sure (2) makes more sense than (1). I'd consider styleSheets as a list of stylesheets associated with any style elements in the shadow DOM. If a style element is inserted into a shadow DOM, I'd expect its stylesheet to exist and present on its shadow root.

[TakayoshiKochi]

I don't have strong preference for either options.

(2) could be consistent with document.styleSheets case in that the array reflects <style>
elements which actually affects the rendering (i.e. until a shadow host is attached to document,
the content of the stylesheet doesn't make much sense).
Although you could argue that (1) is more consistent, in that <style> is counted in shadowroot
when it is attached to its shadow root's tree, like when <style> is counted when it is attached
to document as you mentioned in the comment above.

[annevk]

document.styleSheets doesn't just reflect rendering. Try

<script>
 var d = new Document()
 w(d.styleSheets.length)
 d.appendChild(document.createElement("style"))
 w(d.styleSheets.length)
</script>

in the Live DOM Viewer. It'll log 0, 1.

Given that I think we should go with 1.

[TakayoshiKochi]

We have no objection for going with 1.

@hayatoito could you close this?

[hayatoito]

Per the conclusion of #530, let me re-open this issue.
See also #526.

I think we should parse the content of <style> if and only if it is connected, as I proposed in #526.
Is there any objection? If there is no objection, I will file an issue for HTML Standard.

[annevk]

Only if it is connected, or only if it is browsing-context connected?

[annevk]

I think if we can get away with only browsing-context connected I'd be okay with that. That's certainly the only case where there is a viewport and styling actually makes sense.

[hayatoito]

I prefer "only browsing-context connected" because it is consistent with the conclusion of #530.

[domenic]

Hmm that might not be right though, see whatwg/html#1495 (comment)

In other words I think the browsing context requirement is more about fetching than it is about style application.

[annevk]

Yeah, the question is whether the style application is actually required by the web or not. Seems likely, but worth investigating I suppose.

[hayatoito]

I see. It looks we have two options.

1. UA should process <style> if and only if it is browsing-context connected.
2. UA should process <style> if and only if it is connected.

1 is a strict condition, and 2 is more relaxed condition than 1.

If we forget a shadow tree, the current Web platform is using 2, right? As far as I see in HTML Standard, it looks it does not consider a browsing-context. "in a document"-ness only matters.

[annevk]

Yeah, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2739 is the test noted in the HTML Standard source that indicates a browsing context isn't needed.

[rniwa]

In that browsing context less document, are browsers expected to load external CSS files specified by @import?

[annevk]

So it's rather messy actually. While <style>.sheet returns a stylesheet, document.styleSheets only returns the one from <style> in Firefox. Both Chrome and Safari have document.styleSheets empty, despite <style>.sheet returning a stylesheet.

No browser appears to load @import or cause that to create another stylesheet.

I used variations on this code in Live DOM Viewer:

<!DOCTYPE html>
<script>
 var d = document.implementation.createHTMLDocument();
 var s = d.createElement('style');
 s.textContent = '@import "style"';
 d.documentElement.childNodes[0].appendChild(s);
 w(s.sheet);
 w(s.sheet.cssRules[0].cssText);
 setTimeout("w(d.styleSheets.length)", 500)
</script> 

[rniwa]

If @import doesn't work, it's probably more consistent to not load stylesheets at least inside a shadow tree. On the other hand, we probably can't change the behavior of a browsering-context-less document.

That makes me think that the status quo of letting styles apply but failing to load @import might be the right behavior for a document without a browsing context as well as a shadow tree that is not connected to a document with a browsing context for consistency (since both Document and ShadowRoot has styleSheets, it's weird for them to behave differently).

That is, make style always work in a shadow tree but @import would work if and only if the style element is connected to a document with a browsing context.

[annevk]

I think that is what we have in the HTML Standard now. However, note that in Chrome and Safari document.styleSheets is not actually populated with the stylesheet from <style>. Only <style>.sheet is. But maybe that is something you can fix.

[rniwa]

Yeah, that sounds like just a bug in WebKit/Blink.

[annevk]

Closing this as I think we're good as far as <style> goes standards-wise.