Title: CSS Shadow Parts Shortname: css-shadow-parts Level: 1 Group: CSSWG Status: ED Work Status: exploring URL: http://drafts.csswg.org/css-shadow-parts/ Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/, w3cid 42199 Abstract: This specification defines the ''::part()'' and ''::theme()'' pseudo-elements on shadow hosts, allowing shadow hosts to selectively expose chosen elements from their shadow tree to the outside page for styling purposes.
spec:selectors-4;
type:selector; text::hover
type:dfn; text:live profile
type:dfn; text:structural pseudo-class
spec:dom; type:dfn; for:/; text:shadow root
spec:infra;
type:dfn; text:string
Introduction {#intro}
=====================
Issue: This spec is intentionally a rough sketch at the moment.
It should contain all the details necessary to evaluate the proposal,
but is intentionally avoiding precise algorithms at the moment,
to aid in easy comprehension
and to, hopefully, discourage implementation from this sketch.
Shadow DOM allows authors to separate their page into "components",
subtrees of markup whose details are only relevant to the component itself,
not the outside page.
This reduces the chance of a style meant for one part of the page
accidentally over-applying and making a different part of the page look wrong.
However, this styling barrier also makes it harder for a page to interact with its components
when it actually wants to do so.
This specification defines the ''::part()'' and ''::theme()'' pseudo-elements,
which allow an author to style specific, purposely exposed elements in a shadow tree
from the outside page's context.
In combination with custom properties,
which let the outside page pass particular values
(such as theme colors)
into the component for it to do with as it will,
these pseudo-elements allow components and the outside page
to interact in safe, powerful ways,
maintaining encapsulation
without surrending all control.
Motivation {#motivation}
------------------------
For obvious reasons,
it's valuable to let the outside page style the internals of a shadow tree,
at least in some limited ways.
(The ubiquity of UA-specific pseudo-elements for the various input elements shows this.)
The previous proposed method for doing so,
the >>> combinator,
turned out to be too powerful for its own good;
it exposed too much of a component's internal structure to scrutiny,
defeating some of the encapsulation benefits that using Shadow DOM brings.
For this,
and other performance-related reasons,
the >>> combinator was eventually removed from the live profile.
This left us with using custom properties as the only way to style into a shadow tree:
the component would advertise that it uses certain custom properties to style its internals,
and the outer page could then set those properties as it wished on the shadow host,
letting inheritance push the values down to where they were needed.
This works very well for many simple theming use-cases.
However, there are some cases where this falls down.
If a component wishes to allow arbitrary styling of something in its shadow tree,
the only way to do so is to define hundreds of custom properties
(one per CSS property they wish to allow control of),
which is obviously ridiculous
for both usability and performance reasons.
The situation is compounded if authors wish to style the component differently
based on pseudo-classes like '':hover'';
the component needs to duplicate the custom properties used
for each pseudo-class
(and each combination,
like '':hover:focus'',
resulting in a combinatorial explosion).
This makes the usability and performance problems even worse.
We introduce ''::part()'' to handle this case much more elegantly and performantly.
Rather than bundling everything into custom property names,
the functionality lives in selectors and style rule syntax,
like it's meant to.
This is far more usable for both component authors
and component users,
should have much better performance,
and allows for better encapsulation/API surface.
Another interesting facet of using custom properties,
however,
is that inheritance doesn't stop at the first shadow tree.
Unless explicitly blocked,
a custom property inherits down thru nested trees,
allowing authors to style deeply nested components
as easily as they style directly-visible ones.
The same considerations apply to this case,
so we introduce ''::theme()'' to handle this.
It's important to note that ''::part()'' and ''::theme()''
offer absolutely zero new theoretical power.
They are not a rehash of the ''>>>'' combinator,
they're simply a more convenient and consistent syntax
for something authors can already do with custom properties.
By separating out the explicitly "published" parts of an element
(the shadow part map
from the sub-parts that it merely happens to contain
(the computed shadow theme map,
it also helps with encapsulation,
as authors can use ''::part()'' without fear of accidental over-styling.
Exposing a Shadow Element: the <{html-global/part}> attribute {#part-attr}
=============================================================
Any element in a shadow tree can have a part attribute.
This is used to expose the element outside the shadow tree,
and to "forward" sub-parts of the element
(if it has its own shadow tree)
to outside the shadow tree.
The part attribute is parsed as a comma-separated list of part mappings.
Each part mapping is one of:
ident
:: Adds «[ ident → el ]» to the shadow root's shadow part map.
: ident1 => ident2
:: If el is a shadow host,
and it's shadow root's shadow part map |partMap| [=map/contains=] ident1,
then this adds «[ ident2 → |partMap|[ident1] ]» to the shadow root's shadow part map.
: * => prefix*
:: If el is a shadow host,
then [=map/for each=] |ident| → |subEl| in el's shadow root's shadow part map,
«[ prefix + |ident| → |subEl| ]» is added to the shadow root's shadow part map.
: anything else
:: Ignored for error-recovery / future compat.
::part() = ::part( <> )
::theme() = ::theme( <> )
The ''::part()'' pseudo-element only matches anything
when the originating element is a shadow host.
If the originating element's shadow root's shadow part map
[=map/contains=] the specified <part="label"),
you can select it with
''#the-button::part(label)''.
part="label"
anywhere in the entire document,
no matter how deeply nested into shadow trees they are.
<x-panel>'s internal confirm button had used something like
part="confirm-button, * => confirm-*"
to forward the button's internal parts up into the panel's own shadow part map,
then a selector like
''x-panel::part(confirm-label)''
would select just the one button's label,
ignoring any other labels.