Should <link rel="stylesheet"> work inside shadow DOM?

[domenic]

Right now it uses "in a document", meaning we are not sure whether it should be "in a document tree" or "connected": https://html.spec.whatwg.org/multipage/semantics.html#link-type-stylesheet:concept-link-obtain

I think we should allow this (i.e. switch to "connected"). If we allow <style>, why not <link>?

[rniwa]

Also see #526

[hayatoito]

• link is banned in a shadow tree.
  See http://w3c.github.io/webcomponents/spec/shadow/#inertness-of-html-elements-in-a-shadow-tree
  We can replace "in a document" with "in a document tree" for link.
• Regarding style, yeah, see ShadowRoot.styleSheets should return an empty StyleSheetList if the shadow root is not connected #526. The current blink's implementation: we allow <style> if and only if it is connected.

[rniwa]

I don't think restricting link element to the document tree makes much sense. We should allow it in shadow trees.

@travisleithead @annevk

[rniwa]

On my second thought, I do recall a discussion about not allowing loading of external scripts and stylesheets to discourage people from loading the same styles/scripts multiple times in a single page.

[annevk]

We already decided to allow scripts. I'm fine with allowing this as well. Presumably long-term this will mostly be done through an API.

[rniwa]

On the other hand, it might be wise to not allow stylesheets or scripts to be loaded in shadow tree until that we figure out what we want to do with the new thing though. Otherwise, we may end up tying ourselves to some undesirable constraints.

[TakayoshiKochi]

As @annevk already pointed out, in long-term we would use constructable stylesheets
http://tabatkins.github.io/specs/construct-stylesheets/.

Just for historical reference, some discussions related to this:

• https://bugs.chromium.org/p/chromium/issues/detail?id=313458
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=22539
• [Shadow]: Add support for external stylesheets using link rel="stylesheet" (bugzilla: 22539) #82

[domenic]

It seems like the argument against is that UAs are able to optimize <style> with the same text content appearing many times in the same document, but are not able to optimize <link rel="stylesheet"> with the same href.

Is that completely true? Even if the response has appropriate long-lived caching headers? I guess on initial page load with an umprimed cache it would probably still make a bunch of requests, which is bad?

[hayatoito]

Yeah, I think UA can optimize it in theory, but such an optimization is not guaranteed by the spec. As far as I remember, that was a concern from web developers.

Thus, we want to provide a standard way where such an optimization is strongly guaranteed.

[domenic]

Hmm. I don't find that compelling, because as a web developer it seems like the same argument applies to multiple <style>s. That is, in theory it can be optimized so that the UA does not parse it multiple times or do other work, but in practice it is not guaranteed. (I think Apple has in fact stated they have such an optimization ready, whereas Google is pushing constructible stylesheets because they do not, if I recall previous discussions.)

Maybe it is an issue of degree of badness? Multi-parsing is not as bad as multi-fetching?

In general any asymmetry between <style> and <link rel="stylesheet"> is really surprising for web devs IMO...

[annevk]

Yeah, and given <style>@import ...</style> it doesn't make sense to support one and not the other. We should just allow both.

[hayatoito]

Thanks. I do not have a strong opinion on this issue, historically. :)
I am totally okay to allow <link rel="stylesheet"> if it is connected, hoping that web developers would use it in a good manner.