The ::part() pseudo-element allows you to style specific parts of a Web Component's shadow DOM from outside the component. It works in combination with the part attribute inside the component's shadow DOM to expose internal elements for styling.

Key Points

1
::part(name) targets elements inside a shadow DOM that have a part="name" attribute.
2
It allows encapsulated components to expose certain internal elements for styling while keeping the rest of the shadow DOM private.
3
You can style properties like color, background, padding, border, and more on the exposed part.
4
Multiple parts can be targeted by separating names with commas, e.g., ::part(header, footer).

Example: Styling a Web Component Part

In this example, the ::part() pseudo-element is used to style the title and content parts of the <my-card> Web Component. Even though these elements are inside the shadow DOM, they are styled externally without breaking encapsulation.

Best Practices

1
Use part attributes inside Web Components to expose only the elements intended for external styling.
2
Combine ::part() with CSS variables for flexible theming and styling.
3
Avoid exposing unnecessary internal elements to preserve encapsulation.
4
Test across browsers, as support for ::part() may vary slightly in older versions.

Difficulty: 6/10

Topics: Shadow DOM styling, CSS custom properties, component theming

Scenario Questions

0-2 years experience

1
You're building a custom button component with a shadow DOM, and you want the parent page to change the text color of the button's label. How would you expose and style that label using ::part()?
2
If you forget to add the part attribute to an element inside your shadow DOM, what happens when you try to style it with ::part() from outside?

2-5 years experience

1
A team member reports that their custom card component's header isn't responding to ::part(header) styles anymore — the component hasn't changed, but the CSS rule was working last week. What would you check first?
2
You're building a themable date picker component. You want to let consumers style the selected day and the calendar grid separately. How would you design the part names and what tradeoffs would you consider versus using CSS custom properties?

5-8 years experience

1
You're designing a design system with 50+ Web Components that need to support enterprise theming. How would you structure your ::part() API to balance flexibility with maintainability, and what edge cases might break downstream consumers?
2
A legacy component uses ::shadow and deep selectors for theming. You're migrating to ::part() but some styles are now broken because the internal structure changed. How do you plan the migration without breaking existing themes?

8+ years experience

1
Your company is standardizing on Web Components across 15 product teams. How would you design a governance model for ::part() exposure — what criteria determine whether an internal element gets a part, and how do you handle breaking changes when parts are removed?
2
You're evaluating whether to adopt ::part() as the primary theming mechanism for your design system. What long-term maintenance, accessibility, and cross-team adoption risks would you surface to leadership, and how would you mitigate them?

Follow-up Questions

❓What happens if a consumer tries to style a part that wasn't declared in the component?
❓How would you handle theming if you needed to style elements conditionally based on user preferences?
❓Can you use ::part() with CSS custom properties? How does that interact?