CSS Custom Properties Penetrate the Shadow DOM

One of the whole points of the Shadow DOM is that it provides encapsulation. No styles out, no styles in. But there are ways "through" the Shadow DOM, and one of them that is pretty cool and useful is using CSS custom properties on particular elements/properties.

[dansnel]

you forget to mention css fallback properties. I like the originality of this clip.

[tobz-nz]

I use this a lot with svg's the same way you did at the start. But i set the fallback value for the var to `currentColor` so it inherits the pages color by default.
e.g. `fill: var(--icon-color, currentColor)`. So the color is inherited by the normal cascade, but can be set specifically if required. Super useful.

[Jlbow]

Did you know things like HTMLParagraphElement exist as an extend for the class

[LeoPlaw]

To access the internal elements of a custom DOM, I can also set up getters and setters within the Web Component.
get rows() { return }
CSS Custom Properties are very useful for penetrating the Shadow DOM, but you can gain specific control by exposing the internal elements through the getters and setters.
The two together give you complete external control of your Web Component.

[zoso]

9:01 "extends HTMLElement...it's all you can extend". One *can extend HTMLInputElement* but then *can't attach shadow root to that component* .

[catalicos]

Very interesting! Didn't know that about the custom properties.
But on the topic of SVG sprites, I was actually building a new project, using an SVG sprite and what I wanted was to be able to overwrite a default color (fill) by adding a class on the SVG element that actually renders the icon (with <use>). The problem was that the paths contained a fill attribute (as exported from Figma), so I did not find a way to overwrite that fill attribute value (using only CSS) 😕I had to delete the attribute so to avoid `!important` declarations, etc.
The same in your example here, I would want to control, or better said, overwrite a default CSS defined fill color, from the SVG <use> element and not inside the symbol itself.
I did not consider using custom properties for this purpose although I will use them for the project. I just didn't think it would make a difference. It still might not help, since the path fill attribute was the actual problem, but I'll give it a try with a different spin to it. It might help anyways, with the overwrites. Thanks for the info!

[TroubleTelevision]

Great video! Though the ${this.innerHTML} can be replaced by <slot></slot>, to be semantically correct & 'independent' of JavaScript. Slotting by default will take the children. In addition: i also think that you are not really penetrating the ShadowDOM this way, since the innerHTML will reference the "real" element, but since attachShadow prevents the innerHTML from rendering, you basically just reference the upper level element. Not tested though, just a consideration.

[szeredaiakos]

Complete encapsulation and complete layering are both bad practices.
The shadow-dom forces you towards full encapsulation. Which is bad. Naturally, you'll find yourself loading up the entire global stack into each custom element and ... things go downhill fast.

It wasn't chrome eating up the ram. And the not-chrome in the future will eat up even more. XD

We'll end up with an adobe flash scenario again.