Skip to content
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

CSS encapsulation and common CSS rules #800

Closed
goldingdamien opened this issue Feb 28, 2019 · 13 comments
Closed

CSS encapsulation and common CSS rules #800

goldingdamien opened this issue Feb 28, 2019 · 13 comments

Comments

@goldingdamien
Copy link

goldingdamien commented Feb 28, 2019

  1. Currently(deprecated or not) is there a way to apply CSS to children shadow DOMs?

  2. Are all future plans for CSS encapsulation to not allow a way for parent DOMs to affect children shadow DOMs?

  3. Duplicating CSS for each shadow DOM to achieve common CSS rules leads to a waste of resources. Is there a way for or any plans for references to style elements, etc., so that common css can be created once and referenced multiple times by other DOMs?

@andyearnshaw
Copy link

Yes, there's constructable stylesheets. Part of that proposal was DocumentOrShadowRoot.prototype.adoptedStyleSheets. An implementation is available in Chrome 73.

@goldingdamien
Copy link
Author

@andyearnshaw Thanks. That answers my third question.

@andyearnshaw
Copy link

Sorry, skim read and didn't answer the whole thing. Currently, there's no way to apply CSS to descendant shadow trees. There's a shadow parts proposal that would enable a component author to expose parts of the descendant shadow trees. There's no way to style arbitrary elements inside a shadow tree, there were selectors for this originally but they were dropped from the specification and are not supported by any browser implementations that are based on the "v1" spec.

@hayatoito
Copy link
Contributor

Yeah, let me summarize, and close the issue.

  1. CSS Shadow Parts (::part and ::theme) is the only way. Chrome will ship ::part soon in M73.
  2. No future plan other than CSS Shadow Parts, as of now.
  3. construtable stylesheet was exactly introduced to resolve this waste of resources problems. Chrome will ship it in M73.

@bkardell
Copy link

bkardell commented Mar 1, 2019

Since the op asked 'deprecated or not' there was also an early stab at combinators for 'drilling down' but those received some bad feedback and directions changed.

@hayatoito
Copy link
Contributor

hayatoito commented Mar 1, 2019

@bkardell
Yeah, Chrome had /deep/ combinator for v0, however, it's history. v1 never implements that.

@Lonniebiz
Copy link

Lonniebiz commented Jul 14, 2019

I believe you should be able to link to an external style sheet from within the Shadow DOM.

I've been wanting something similar since 2005.

Just because the style sheet is external, doesn't mean its rules must apply to anything outside of the shadow dom that contains that link.

I have some custom elements that recur on a page one hundred times. It seems wasteful (upon inspecting the document's shadow dom nodes) that each of those shadow dom nodes contains an identical copy of a pretty lengthy set of CSS rules within each shadowDom's style tag.

Wouldn't it be more efficient if each shadow dom could linked to an external style sheet instead? The browser would cache that external resource after the first download of it, and use that cache for each recurring element's link to that same sheet.

I realize, that no matter where a style comes from, the browser still has to apply that style just as much, and it could be, that behind the scenes the browser is doing something way more efficient that what appear so redundant during document inspection. Yet, on the surface it appears excessively redundant and I've been wanting the ability to link to external style sheets, from within components (with component-level scope), for a long time now.

@hayatoito mentioned constructable-stylesheets, I'm reading about it now.

@emilio
Copy link

emilio commented Jul 14, 2019

<link rel="stylesheet"> inside a shadow tree works everywhere as far as I can tell, doesn't it?

@rniwa
Copy link
Collaborator

rniwa commented Jul 14, 2019

Wouldn't it be more efficient if each shadow dom could linked to an external style sheet instead? The browser would cache that external resource after the first download of it, and use that cache for each recurring element's link to the same sheet.

The browser would do this for all sub-resources regardless of where they appear. Browser engines can also cache the result of parsed CSS, etc... whenever the same CSS appears in multiple shadow trees.

Constructable stylesheets, if implemented in WebKit, will probably be not anymore efficient than just using style element in each shadow tree in any meaningful way.

@Lonniebiz
Copy link

Lonniebiz commented Jul 15, 2019

<link rel="stylesheet"> inside a shadow tree works everywhere as far as I can tell, doesn't it?

@emilio : When <link rel="stylesheet"> is used from within a shadowDOM, does it properly apply style to only that shadowDOM's scope? Before shadowDOM, this was the issue I had with <link rel="stylesheet"> (as mentioned in 2005). Is this still the case from within shadowDOM?

ShadowDOM is supposed to encapsulate style. I'd consider it a bug if it doesn't also do this when an external style sheet is imported into the shadowDOM.

@Lonniebiz
Copy link

Lonniebiz commented Jul 15, 2019

I need contructable stylesheets in Firefox!

@emilio
Copy link

emilio commented Jul 15, 2019

@emilio : When is used from within a shadowDOM, does it properly apply style to only that shadowDOM's scope?

Yes it does.

@rniwa
Copy link
Collaborator

rniwa commented Jul 16, 2019

@emilio : When <link rel="stylesheet"> is used from within a shadowDOM, does it properly apply style to only that shadowDOM's scope? Before shadowDOM, this was the issue I had with <link rel="stylesheet"> (as mentioned in 2005). Is this still the case from within shadowDOM?

That should work fine in all browsers now. That's sort of the whole point of shadow DOM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants