Webcomponents: Should <link> work inside Shadow DOM?

[tomalec]

After https://github.com/w3c/webcomponents/issues/530, to keep <style> & <link rel="stylesheet> consistent, both works inside Shadow DOM. My question is, how about consistency with other link types (rels)?
What about author or ekhm.. import?

I would like to indicate an author of the document fragment I attached to shadow root, as well as custom element definitions bulked with CSS in imports. I know imports are on hold, but is there a reason to exclude all links except stylesheet? Or to block loading external document fragments into shadow root?

They are excluded explicitly at http://w3c.github.io/webcomponents/spec/shadow/#dfn-inert-in-a-shadow-tree but I cannot find anything similar at https://html.spec.whatwg.org/. I'm not sure whether this is still to be upstreamed (https://github.com/w3c/webcomponents/issues/377#issuecomment-250693594) or this constraint was dropped.

Current Blink implementation blocks all <link> elements except stylesheet what results in "HTML element <link> is ignored in shadow tree." warning, which is not so precise, as in fact not all <link> elements are ignored.

To draw my use-case: I use Shadow DOM for styling 3rd party content. So, not to break functionality, I attach HTML composition to Shadow Root.
https://starcounter.io/unobtrusive-styling-composing-3rd-party-html-content/
The problem is that, I would like to use custom elements (both vanilla and Polymers) which are delivered with CSS rules.

[tomalec]

This also blocks the use of custom built-ins which extends link or meta in Shadow DOM

[rniwa]

Is your primary use case about pulling content in with HTML imports inside a shadow tree? If so, given the lack of appetite for HTML imports from browser vendors other than Google, I'm not certain if it's even valuable to spec such a behavior. It won't work on any browser but Chrome.

I use Shadow DOM for styling 3rd party content. So, not to break functionality, I attach HTML composition to Shadow Root.

I don't follow. What exactly is a use case? A use case should concern a very specific scenario in which a very specific instance of link element is used, not some vague notion that you'd like be able to use link element inside a shadow tree to do composition.

[hayatoito]

but is there a reason to exclude all links except stylesheet?

There is no clear reason, AFAIK. We are banning other rels because we have not discussed other rels seriously yet, except for rel=stylesheet. We are lazy because other rels have not got much attentions so far.

If we can find any good use case for other rels, we might add it into the "allowed list", I think.

[nektro]

Does this not attempt to solve the same problem as the deep combinator (/deep/ / >>>)?

[annevk]

@hayatoito where is it defined that rel=stylesheet should work?

[hayatoito]

We have updated HTML Standard for rel=stylesheet: https://github.com/whatwg/html/commit/43c57866c2bbc20dc0deb15a721a28cbaad2140c

[annevk]

Oh I see, so now the "Shadow DOM" document both contains incorrect information for some features and the only information for some other features. Hmm.

It would be better if we indicated that more clearly in http://w3c.github.io/webcomponents/spec/shadow/#html-elements-in-shadow-trees. Then this issue can be refiled against whatwg/html though if it's just about import it's invalid as that's a proprietary feature.

[hayatoito]

Yeah, that was my fault. Let me clarify the status of <link> there.

[annevk]

I'm going to close this based on the added note. If any cases besides import come up, please raise them at https://github.com/whatwg/html/issues/new. Thanks!

[rmedaer]

@annevk It would be really useful for lazy-loading HTML fragment through web components. Is it a valid use case to open an issue on whatwg/html ?

[annevk]

If by it you mean import, then no. We are discussing something called HTML modules in this repository though that should allow for such functionality.