Dave rounds up some of the acronymtastic ways of scoping your CSS now that we’ve got a whole new toolkit at our disposal.
If your goal is to reduce specificity, new native CSS tools make reducing specificity a lot easier. You can author your CSS with near-zero specificity and even control the order in which your rules cascade.
This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSS’s cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if it’s just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
A beautiful piece of writing from Virginia Heffernan on how to cope with navigating the overwhelming tsunami of the network.
The trick is to read technology instead of being captured by it—to maintain the whip hand.
Monica explains how Shadow DOM could be the perfect answer for scoping CSS:
We didn’t have style encapsulation, so we started naming things “the right way” with BEM, so that we didn’t accidentally stomp over each other’s styles. We wanted to be able to author CSS from inside a JavaScript component, so we started using CSS-in-JS. We needed all these tools, because “the platform” (read: the browsers that be) wasn’t there, and building these tools showed that there was a need to move forward. For style encapsulation, Shadow DOM is the platform moving forward.
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Before you complain that using a Shadow DOM and Web Components means that it absolutely requires JavaScript: this is true.