Styling in the Shadow DOM With CSS Shadow Parts

Safari 13.1 introduced support for CSS Shadow Parts, which means that the ::part() selector is now supported by Chrome, Edge, Opera, Safari, and Firefox. This article will explore its uses and first review the packaging features of Shadow DOM.

Advantages of Shadow DOM Packaging

At giffgaff, we have a large amount of CSS code written by different people in many different ways. Let's see what problems this may bring.

Naming conflict

Class name conflicts are prone to occur in CSS. A developer may create a class name called .price . Another developer (and maybe even the same person) may use the same class name without knowing it.

CSS will not prompt any errors. Now any HTML element with this class will receive styles for two completely different things.

Shadow DOM resolves this issue. CSS-in-JS libraries like Emotion and styled-components also solve this problem in different ways by generating random class names such as .bwzfXH . This certainly helps avoid conflict! However, CSS-in-JS does not prevent anyone from breaking your components in other ways. For example……

Basic Styles and CSS Reset

HTML element selectors can be used (e.g.<button></button> and<div> ) Apply styles. These styles may break the component. Shadow DOM is the only mechanism that provides (almost) fully encapsulated-you can rest assured that your components will look consistent even in a messy <code>!important code base, because each component is encapsulated.

 /* This will not affect the buttons inside the Shadow DOM*/
button { background-color: lime !important; }

I don't think it's a good practice to style the element this way, but it does happen. Even if this happens, these styles do not affect the Shadow DOM.

It is worth noting that inheritable styles like color, font, and line height are still inherited in Shadow DOM. To prevent this, use all: initial or preferably all: revert after the browser supports better.

Let's look at a common example of CSS applied directly to HTML elements. Consider Eric Meyer's reset code:

 html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small strike strong sub sup tt var
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embedded,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}

What happens if the component we are using uses the default margins and padding values ​​for the user agent? This reset may cause it to look corrupted, as these default values ​​are actually cleared.

Shadow DOM is a way to avoid these problems. Shadow DOM enables us to be fully convinced that the component will render as expected, no matter which code base it ends up in. Again, no code that is used only for components will inadvertently affect anything else—all without the cumbersome class naming conventions. Shadow DOM provides an encapsulation level that cannot be achieved in other ways.

The packaging is great, but we also want our components to be themed and customizable. ::part selector makes this much easier.

Style Shadow DOM with ::part()

So far, the only way CSS can modify custom element styles from outside Shadow DOM is to use CSS custom properties. In a strict design system, you only want to allow limited changes, which may be ideal. If you want your component to be more general, it can create problems. You need to use custom properties to define each CSS attribute you want to provide for style. It just sounds very complicated.

If we want to style components in different ways based on pseudo-classes (such as :hover ), the situation will be further complicated. Basically, we end up with a lot of custom properties. Let's look at an example from Ionic (a set of open source web components). Take a look at all the custom properties defined on the Ionic button component.

Feel free to check it out.

I counted 23 custom properties. Needless to say, this is far from ideal.

Here is an example of using ::part() to style elements.

In this example, I just changed the color, border and background color properties, but I can use any property I want without being limited by the custom properties that have been defined. Note that I can also use pseudo-classes such as :hover and :focus to style the different states of the component.

In this button example, the entire component is exposed for style setting, but if your web component contains multiple HTML elements, you can expose only selected parts of the component to this style setting - hence the name ::part . This prevents the component's users from styling any arbitrary elements within the Shadow tree. Component authors are responsible for revealing the components that they explicitly want to disclose. Other parts of the component can maintain visual consistency or use custom properties to achieve less customizability.

So, how do we set this for our components? Let's see how to use ::part to make certain elements of a web component styling. All we do is add a part property to the element we want to expose.

<div part="box"> ...</div>
<button>Click me</button>

In this example, div can be customized using the full CSS scope—any CSS attribute can be changed. But the button is locked – no one can change its visual effects except the component author.

Just as HTML elements can have multiple class names, one element can also have multiple part names:

<div part="box thing"> ...</div>

This is what we get with ::part : By exposing the "part" of the element, we can provide some flexibility on how to use web components while protecting them in other areas. Whether it’s your design system, component library, or anything else, the fact that CSS Shadow Parts is becoming mainstream provides us with another exciting tool.