[css-shadow-parts-2] Add part-name CSS property #10988
Description
Currently to surface a part for consumption the name of the part needs to originate from an HTML attribute:
<shadow-host>
<template shadowrootmode="open">
<button part="button">Click me!</button>
</template>
</shadow-host>Then later, in CSS, the element can be selected as follows:
::part(button) {
/* ... styles ... */
}I have realized that this is very close to the syntax for View Transitions:
::view-transition-group(...) {
/* ... styles ... */
}However, View Transitions are not required to use a attribute to make this association, they are given the view-transition-name property to do this instead.
.element-to-transition {
view-transition-name: ...;
}This maintenance of the application and consumption of values in the same language space is quite nice...
The part-name property
Can CSS Parts have a reciprocal part-name property?
With a new property along these lines, the previous example would look as follows, with the consumption of the part remaining the same:
<shadow-host>
<template shadowrootmode="open">
<style>
button {
part-name: button;
}
</style>
<button>Click me!</button>
</template>
</shadow-host>While it may initially seem more verbose, in most cases elements that are exported as parts are already getting some sort of default styling so adding one line to that would be much more akin to the code require for part="...". What's more, the part being bound to a CSS construct would simplify the need seen in a lot of part="..." usage of paralleling that with a class or other attribute values for styling.
Possibilities
With this move export parts could also be moved into the CSS realm, and work something like:
<shadow-host>
<template shadowrootmode="open">
<style>
::part(button) {
part-name: button;
}
</style>
<custom-button>
<template shadowrootmode="open">
<style>
button {
part-name: button;
}
</style>
<button>Click me!</button>
</template>
</custom-button>
</template>
</shadow-host>This may also open the door for more flexible syntaxes in this are as requested/planned in WICG/webcomponents#1051 and #3422 et al.
What other possibilities do you see coming from such an addition to the ::part(...) API?
Potential issues
CSS Parts can be addressed "internally" from the outside via :host::part(...). What happens when you rename such a part?
<shadow-host>
<template shadowrootmode="open">
<style>
:host::part(button) {
part-name: not-button;
}
</style>
<button part="button">Click me!</button>
</template>
</shadow-host>- Is this a weird cycle that blocks the whole idea?
- Is this the element leveraging the external nature of the
:hostselector (reminder:hostdoesn't technically exist in the shadow root) to self name the part for reexporting into the grandparent DOM tree? - Is this a reason to not allow
part-namein:hostselectors? - Is this a reason to not allow
part-namein::part(...)selectors?
What other potential issues do you see getting in the way of such an addition to the ::part(...) API?