# Styling the Shadow DOM: Encapsulation, Host Styling, and Style Boundaries

DevFeed: [Styling the Shadow DOM: Encapsulation, Host Styling, and Style Boundaries](<https://devfeed.tech/articles/styling-the-shadow-dom-or-a-metaphor-gone-too-far-35546.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/styling-the-dome/>)

Author: Monica Dinculescu

Published: 2015-09-29T00:00:00Z

Content type: opinion

Language: en

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

Topics: [Document Object Model (DOM)](<https://devfeed.tech/topics/dom.md>), [CSS](<https://devfeed.tech/topics/css.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [background](<https://devfeed.tech/tags/background.md>), [change](<https://devfeed.tech/tags/change.md>), [color](<https://devfeed.tech/tags/color.md>), [css](<https://devfeed.tech/tags/css.md>), [input](<https://devfeed.tech/tags/input.md>)

## AI overview

This article explains how the Shadow DOM encapsulates the implementation and styles of custom elements, preventing styles from leaking in or out. It also describes styling the host element while keeping the element's internal implementation isolated.

## Source excerpt

One of the beefs (and there aren't many) that I have with CSS is that it has a very weak opinion about style encapsulation. That opinion is basically "well, name your classes well" or else bad things happen. Know this: I come from C++, land of rules and disappointed compilers; this hand waviness drives me crazy. This matters because now you have to trust the people that write your css libraries to have common sense. If my website needs two kinds of fancy buttons, which live in shiny-button.css and bouncy-button.css, which are both libraries written by silly people who want me to use the .button class to get their style, I'm hosed. Enter the Shadow DOM The Shadow DOM fixes this problem by building a little castle (a dome, get it?) around each custom element, locking in its implementation and styles. This is a proper castle, with a proper moat, so now styles can't get in and out of it. This means that if <shiny-button> was a custom element instead of a pile of CSS, its .button class was scoped to the element itself, and wouldn't stomp over <bouncy-button>'s similarly creatively named .button class. This shouldn't surprise you too much, as native elements have been doing this in secret for yeaaaaars. <input type=date> styles the date picker somehow, but you've never worried what class names it might use to do so. You know why? Because you can't get to its castle, that's why. The struggle is real So what happens if you do want to style <shiny-button>? What if it's a perfectly respectable button, but it uses Helvetica as its font and you really need it to be Comic Sans because Helvetica is so 2014? You can always style the host of the element. Think of the host as the castle walls; it's the thing that holds all the actual contents of the custom element. It still plays by CSS rules, so some of the styles you set on the host could actually trickle down to some child elements. For example: shiny-button { color: white; background-color: tomato; border-radius: 3px; width: 400