Thanks, didn't know about part and theme - and again, I'm not sure if I like it. For example angular puts [innerHTML] into a shadow container - let's assume we are talking about arbitrary localized text from a cms, heavily sanitized, with basic html elements allowed only. With both deep and apply going the way of the dodo, I'm not sure when will we have part and theme support, but heck, this again, just like css variables, need an effort on the 3rd party's side (to add part descriptors and chain prefixers - gosh, those prefixers sure smell bemish), which may or may not happen.
All I need is a fail safe way of modifying style inside shadow containers without the 3rd party adding support for it (right now we are modifying an angular material based site, because, you know, before the release the most important thing is that how these elements animate or how their drop shadow look), fail safe meaning that it should not be possible to accidentally overwrite stuff inside shadows (like generic link styling).
But probably it's a conflict of interest... everyone wants perfectly contained elements (because css is scary) but wants to retain maximum customizability without modifying the upstream package, plus we don't want shadow contained css to be duplicated. Not sure if there's a good solution for that.
That’s what CSS parts and slots are for. Your component can style its own boundaries, provide parts to allow customisation, and use slots to inject components that are styled from outside (be it another ShadowDOM or the light DOM)
Not really, the shadow DOM is an opt in choice for that reason. Only a subset of cases do you actually want the styles to be encapsulated. The shadow DOM is actually harmful for form components as interactive relations are voided if there is a shadow barrier between them (which has implications on both UX and accessibility; I think there is an effort in WHATWG to fix this). But when there is a usecase, the shadow DOM can be really nice. As you get nice things like component scoped styles and unique idref, among others.
> All the blogs I read spoke about exposing a styling api using css variables.
This might be an outdated advice. You are supposed to use a mix of CSS variables and ::part()[1]. CSS variables should cover the most basic styling while you are supposed to expose style-able elements of your components with the part attribute.
I had a look through the docs, and this looks really nice - a great collection of components, and well documented too!
I'm new to web components though, so I was surprised when I saw in the docs that you need to use the CSS `::part` selector to style components, rather than simply using more "traditional", well-known CSS. Is this a result of using a shadow DOM? If so, what benefits does using a shadow DOM use for these components?
All these abstractions over CSS seem way to complicated and many way to far from the browser to me.
With Shadow DOM style scoping, CSS custom properties and @apply mixins all coming very soon, most of the problems of composable, reusable styling, and even theming, will have great native solutions.
I'd like to see more focus on reusable polyfills than trying to divert around CSS. Polymer supports all three of those now, but they're pretty tightly integrated so other frameworks can't use them so easily yet.
It's been a while since I dipped into it, but Web Components use this thing called Shadow DOM to encapsulate the CSS inside from being affected by the stuff outside. Great for compartmentalization, but unnecessary for my personal needs.
So if you're curious about the concept, check out Custom Elements. Same thing, but no Shadow DOM. I found them to work quite well for a toy project I made a couple years ago.
Interesting. What is the added styling complexity? I am interested in using Shadow DOM for the next version of my component DataGridXL (https://www.datagridxl.com/) to prevent outside CSS from affecting the component. WHy do you say it is not worth it?
Doesnt the shadow-dom solve the problems with css modularity. You just write the css for your component, and it doesnt leak into anything else... Why do you need something like css-modules?
Shadow DOM is a nice touch and in terms of isolating CSS definitions per-component, it does something beyond what most popular front frameworks can do. That said, I know some developers don't even use the shadow DOM; you can use inline styles like some people do with React or you can use a centralized stylesheet for skinning and only write barebones CSS definitions as part of components.
> However, there's this nagging feeling at the back of my mind that if every component in your app has its own stylesheet, your style is maybe not consistent?
I think we can distinguish two orthogonal uses for CCS styles. One is applying a global style to the page/app ("theming", "branding", etc) and the other is for defining the layout of a component. For technical reasons they have lived together, but with shadow DOM One can put the former on a global CSS and the latter togheter with the component. By doing this I think you can remain consistent, in fact I suspect that it may improve consistency since it is better clear what is part of the style (and thus should be respected/changed with care) and what is an implementation detail of a single piece of a page.
Of course the risk of a component "going rogue with styles" exists, but maybe (and now I am just speculating) by adding CSS variables to the mix we can help the single components to be more consistent with the rest of the app.
I completely disagree. After working with component CSS I vomit when I see any CSS not encapsulated to one single component. I don't want to change a global CSS declaration and accidentally change something completely different. You can always import the stuff you really want shared.
Shadow DOM and it's scoped styling is going to help this situation so much.
Instead of large stylesheets with tons of highly-specific selectors, and quite a few broken and unused rules, web components will be able to use small stylesheets with simple selectors that only apply to their local scope, and developers will be able to reason about and maintain styles that are limited to a single web component.
Angular implements a polyfill for this. Every angular component has 3 files html, ts, (s)css, and the styles in the components css file are automatically scoped to just the component they apply to. It takes away all the stress of global css selectors, and if you want to share styles you can just have a library of shared styles and import them via scss. It's honestly heavenly and I haven't thought about conflicting selectors in years.
Great write up. Can a web component author create one in such a way that the inner shadow dom styles ARE editable/styleable by the outer or person implementing the custom component?
In the instance of Predix (I peripherally worked on that during my time at GE) and likely EA and every other large Web Component ecosystem you're thinking of, that's desired behavior. The real want is a design system such that things look consistent, but as design systems are CSS only, they aren't smart enough for interactions that require JS. So then the need for a design system becomes a need for components of some kind that include the design. You're looking for components with more adaptable design, but that's just not the intention of these ecosystems. If done with that goal, yes CSS vars take you a little bit of the way, but I think we'll see more power coming to help out soon with Shadow Parts/Theme, CSS Modules, and Scoped Stylesheets. But really, just styling a background? If the component author just left the background: none, you could do whatever you wanted from the outside. It just takes planning - even without the Shadow DOM you still need to plan for proper themeing.
The point of this, imo, though, is instead of having a designer design a bunch of components, you have a designer design a bunch of functional styles that can compose components and still be on-brand. So say you have a component, and you want to add an on-brand/in-style shadow to it, you just add the small-shadow class, instead of digging through the css of other components and copy-pasting their lengthy shadow css. I would use this mainly for shadows, fonts, and margins.
I've just done a small project using web components. I didn't use the shadow dom at all (please note I have no idea what I'm doing).
This was after reading a single hacker news comment saying not to bother with it, after days of research where everything I read spoke about web components and the shadow dom as if they were inextricably linked.
I didn't want the styles to be encapsulated. I wanted the css to cascade in like it does everywhere else. I don't really see many use cases where you would actually want to style a component from the inside and not have the user of the component be able to style it themselves.
All the blogs I read spoke about exposing a styling api using css variables. But by doing that, are you not going to great lengths to recreate what already exists in the normal dom?
That’s kind of the opposite problem that the article mentions though — if every component has its own specific CSS, then you don’t really have CSS, you just have SS. You miss out on the cascading.
I develop things at work similarly to you. JSS where every component has its own style, but you have a common `theme` file so that you can reuse the common styles via a library.
But I have a certain romantic feeling about… what if we could do 90%+ of our styling using these global-per-page rules, and overriding when necessary. The simplicity is really appealing
It's fairly easy to choose between style isolation and no style isolation though. Just change the `this.shadow.innerHTML` in the render to `this.innerHTML`. The encapsulation aspect provides some really nice benefits in many scenarios, so having the option of this is quite nice.
A classic example of why this is beneficial is when creating design system components - you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values (see the accent example the author provides).
CSS variables help here quite a bit. I typically will add in component-specific tokens as css variables, that way I have simple penetration into the shadowdom.
All I need is a fail safe way of modifying style inside shadow containers without the 3rd party adding support for it (right now we are modifying an angular material based site, because, you know, before the release the most important thing is that how these elements animate or how their drop shadow look), fail safe meaning that it should not be possible to accidentally overwrite stuff inside shadows (like generic link styling).
But probably it's a conflict of interest... everyone wants perfectly contained elements (because css is scary) but wants to retain maximum customizability without modifying the upstream package, plus we don't want shadow contained css to be duplicated. Not sure if there's a good solution for that.
reply