# Shadow DOM: fast and encapsulated styles

DevFeed: [Shadow DOM: fast and encapsulated styles](<https://devfeed.tech/articles/shadow-dom-fast-and-encapsulated-styles-35543.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/shadow-dom/>)

Author: Monica Dinculescu

Published: 2017-08-11T00:00:00Z

Content type: article

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [Web Components](<https://devfeed.tech/topics/web-components.md>), [CSS](<https://devfeed.tech/topics/css.md>), [Web platform](<https://devfeed.tech/topics/web-platform.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>)

Tags: [components](<https://devfeed.tech/tags/components.md>), [css](<https://devfeed.tech/tags/css.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [web](<https://devfeed.tech/tags/web.md>)

## AI overview

The article explains how Shadow DOM provides style encapsulation for Web Components by keeping an element's CSS and markup contained. It distinguishes style encapsulation from DOM encapsulation and discusses how tools such as preprocessors, BEM, and CSS-in-JS addressed gaps before platform support advanced.

## Source excerpt

Shadow DOM is a fairly recent-ish spec that gives you DOM tree encapsulation - it's one of the superhero lions in the Voltron of specs called "Web Components". Web Components let you create reusable, self-contained components in JavaScript; the Shadow DOM bit makes sure that the CSS and markup you bundle with your implementation is encapsulated, hiding the implementation details of your element. The idea of encapsulation isn't new - most programming languages have a way to define "private" bits of code - variables or methods that are irrelevant to the user of that object and make the element work. Messing with them usually voids the contract and breaks the guarantee that the element will continue to work. In these languages you could, instead, use a global variable or method for everything. It's not a question of whether it will work (it will), but whether it will work over time, in a large code base (it won't). You know it won't. On the web, there's two kinds of encapsulation we might want: style encapsulation (an element's styles don't leak outside) and DOM encapsulation (an element's internal implementation isn't visible). This post talks about style encapsulation; tune in soon for the second half of the story - the DOM encapsulation! Whew, ok then. So then why is CSS encapsulation so hard? And what's the fastest way to get it? --- Tools to the rescue! 🙏 Before you set me on fire on Twitter, hear this: the next paragraph isn't a criticism of CSS (which I think is the greatest tool for authoring styles) nor a criticism of the tools we use (which I think fill real gaps we have), but a criticism of the standards process itself. I have a theory that developers will put up with too much when it comes to writing CSS. For a while there, CSS wasn't moving forward, so people started using tools to get around that. We didn't have variables or mixins, so we started using preprocessors. We didn't have style encapsulation, so we started naming things "the right way" with BEM,