Open Westbrook opened 5 days ago
The part attribute currently takes a list of values, would part-name allow that?
There's also a .part property which returns a DOMTokenList, if we allow this to be set in CSS that would require a style lookup for this property to work.
A style lookup to resolve .part
would certainly be unfortunate...though would it be prohibative?
Multiple parts is a great point, an approach like this would need to not reduce the API surface, meaning it would need to accept multiple. This of course adds a couple of new "Potential issues":
<button class="thing-1 thing-2">
to have multiple parts, one because of the class thing-1
and another because of thing-2
, there is likely no path to making that possible, at least not without additional changes to the underlying APIs of CSStransform
being broken in scale
, translate
, et al, the inability to easily edit one of the many values of the property.Hrm...but the symmetry with view-transition-name
is so nice.
There's another symmetry to consider and that is symmetry with the slot attribute. It might be confusing to a web developer that you use attributes to identify a slot or slot name, but a CSS property to identify a part.
Currently to surface a part for consumption the name of the part needs to originate from an HTML attribute:
Then later, in CSS, the element can be selected as follows:
I have realized that this is very close to the syntax for View Transitions:
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.This maintenance of the application and consumption of values in the same language space is quite nice...
The
part-name
propertyCan 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:
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 ofpart="..."
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:
This may also open the door for more flexible syntaxes in this are as requested/planned in https://github.com/WICG/webcomponents/issues/1051 and https://github.com/w3c/csswg-drafts/issues/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?:host
selector (reminder:host
doesn't technically exist in the shadow root) to self name the part for reexporting into the grandparent DOM tree?part-name
in:host
selectors?part-name
in::part(...)
selectors?What other potential issues do you see getting in the way of such an addition to the
::part(...)
API?