New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should <link> work inside Shadow DOM? #628

Closed
tomalec opened this Issue Mar 7, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@tomalec
Contributor

tomalec commented Mar 7, 2017

After #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 (#377 (comment)) 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 comment has been minimized.

Show comment
Hide comment
@tomalec

tomalec Mar 7, 2017

Contributor

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

Contributor

tomalec commented Mar 7, 2017

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

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Mar 7, 2017

Contributor

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.

Contributor

rniwa commented Mar 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hayatoito

hayatoito Mar 8, 2017

Member

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.

Member

hayatoito commented Mar 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nektro

nektro Jul 7, 2017

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

nektro commented Jul 7, 2017

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

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 4, 2017

Member

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

Member

annevk commented Sep 4, 2017

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

@hayatoito

This comment has been minimized.

Show comment
Hide comment
@hayatoito

hayatoito Sep 5, 2017

Member

We have updated HTML Standard for rel=stylesheet: whatwg/html@43c5786

Member

hayatoito commented Sep 5, 2017

We have updated HTML Standard for rel=stylesheet: whatwg/html@43c5786

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 5, 2017

Member

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.

Member

annevk commented Sep 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hayatoito

hayatoito Sep 5, 2017

Member

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

Member

hayatoito commented Sep 5, 2017

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

hayatoito added a commit that referenced this issue Sep 5, 2017

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 6, 2017

Member

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!

Member

annevk commented Sep 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rmedaer

rmedaer Jul 17, 2018

@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 ?

rmedaer commented Jul 17, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jul 23, 2018

Member

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.

Member

annevk commented Jul 23, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment