Re: [csswg-drafts] [css-shadow-parts] Unifying ::part() and ::--foo (#4900)

> But by using ::part you're shunting all shadow parts into being a certain type of pseudo-element, rather than allowing custom elements to create their own type of custom pseudo-elements.

No, in the bit you quoted for this response I was referring to my OP (original post), where `part="--foo --bar"` gives you `::--foo` and `::--bar`, and also `::part(--foo --bar)` if you need it.

> If you think of pseudo-elements and pseudo-classes as analogies for elements and classes, it's the case that an element has only one tag name and multiple class names. So perhaps it is right that any given element should only have up to one part name, and optionally multiple state names.

I think it's important not to blindly hew too close to DOM structures - examine *why* we have them and what value they bring.

Tagnames exist because elements have to have a particular identity and behavior; you can't mix-and-match them. It's a required bit of *creating* an element, so the browser knows whether the element should be link-like or button-like or list-like, etc.

But we're not doing that; we're providing ways for component users to *select* elements. And from Selector's POV, there is no meaningful difference between a tagname and a class name - they're both just idents associated with an element. *Because* DOM only allows an element to have one tagname (for the aforementioned reason), tagname selectors are given a syntax that doesn't allow you to specify multiple of them together in a compound selector. But other than that, identical.

So Selectors doesn't provide any reason to create a tagname-like semantic. Is there any value besides that to specially choosing one of the part names as the "tagname" equivalent and making the rest "class name" equivalents? I don't think there is; it seems just as reasonable to select a `::--day` as a `::--monday` or `::--weekend`, etc. I haven't heard anyone provide an explanation of the value so far either, besides "well, elements have tagnames and the ::before kinda looks more like a tagname than a classname".

And note that this corresponds well to the existing selectors authors write for their own component hierarchies, which are *solely* class-based. They don't privilege one name with a special syntax.

> instead we just need to make sure ::--day:--us-holiday works.

I'll refer you again to <> - letting a component give custom pseudo-classes to its parts is going to be *very* fraught, because the sub-component itself (written by a non-cooperating party) is *also* trying to give custom pseudo-classes to itself.

Unless you want to navigate the briar patch I outline in the linked comment, selecting based on states coming from the outer component and states from the inner component *must* use a different syntax.

So, since we're already on the hook for *two* syntaxes (part names from the outside, custom pseudo-classes from the inside), I think we need a *really* good justification for increasing that to *three* (two slightly different notions of "part name").

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Friday, 8 May 2020 22:51:57 UTC