CSS Custom Properties Penetrate the Shadow DOM

[@dansnel]

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

[@jasonneel]

Love the new intro!

[@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 ). 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 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!

[@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.

[@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 this.shadowRoot.querySelector('.rows') } 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.

[@J3lbow]

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

[@TroubleTelevision]

@@realcsstricks You can extend all basic elements, but you need to declare it in the customElements definition (examples to be found here developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements)

[@miklosnemeth8566]

@@realcsstricks 9:14 Yes, you use a syntax like ....

[@AdrianJDeNiz]

So helpful thank you.

[@zoso25]

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

[@TroubleTelevision]

Great video! Though the ${this.innerHTML} can be replaced by , 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.

[@alkdsjfadsf]

Why not fullscreen on the browser?

[@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.

[@miklosnemeth8566]

I full heartedly agree, Akos. Actually, in practice when you create a custom element you don't have to render your template in the shadow dom, you can implement it in the light DOM in innerText and you will have the regular global CSS space, which excellent when you want to use Bootstrap, for example, with custom elements. BUT, there is an (almost (total)) show-stopper: slots don't work in light DOM, only in shadow DOM; that is, you cannot do something like 999Great product Instead, you are forced to apply a workaround (render-props) This would work excellently with a tool like lit-html, Lit Element but far from elegant. It was a crazy opinionated decision of the specification designers not to enable slots for the light DOM either.