-
Notifications
You must be signed in to change notification settings - Fork 373
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
Comments
This also blocks the use of custom built-ins which extends |
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 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 |
There is no clear reason, AFAIK. We are banning other If we can find any good use case for other |
Does this not attempt to solve the same problem as the deep combinator ( |
@hayatoito where is it defined that |
We have updated HTML Standard for |
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 |
Yeah, that was my fault. Let me clarify the status of |
I'm going to close this based on the added note. If any cases besides |
@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 ? |
If by it you mean |
After #530, to keep
<style>
&<link rel="stylesheet>
consistent, both works inside Shadow DOM. My question is, how about consistency with other link types (rel
s)?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 exceptstylesheet
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.
The text was updated successfully, but these errors were encountered: