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

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

It's also important to leverage the existing architecture of the platform and not invent new things when what we have already works.

> 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.

And pseudo-elements already have a particular identity and behavior, giving a pseudo-element a name is part of creating a new pseudo-element.

> 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.

There are differences in the selectors, specificity. There's also a semantic component in the tag name and pseudo-element name.

> 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? 

The value is matching the existing platform rather than inventing something new for no good reason. We already have tag names, pseudo-element names, and classes. Why invent a new 'part name' which is sort of like a class but isn't a class, and isn't selected like a class?

> 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".

Because a 'monday' is a _kind_ of 'day' as is a 'weekend' day, or a 'holiday', there is semantic value here. Allow authors to express that.

Pseudo-elements are also structural, just not structure that's exposed in the DOM, but structure nonetheless that's exposed to selectors. Structural nodes have type names, they may additionally have classes. Class names are not structural, they're descriptive.

Given your calendar widget example, imagine week parts as well as day parts. You could select the third day of the second week as:
`::--week:nth-of-type(2)::--day:nth-of-type(3)` 
rather than:
`::--second-week::--tuesday`
while the first syntax is more verbose, it's also more clear what's going on. It also doesn't rely on decorating each week with a 'first-week', 'second-week', etc and each day with 'monday', 'tuesday', etc, normal structural selector math just works. (And is Tuesday the second or third day of the week in your locale?)

The other aspect here is cow-path paving. Custom elements are supposed to allow web authors to develop new elements that act as much like native elements as possible. Shadow parts as currently proposed only allow custom element authors make a specific kind of pseudo-element (a 'part', which is as semantically valuable as a div) and then use a new and unique way of selecting them.

Some of these inventions are intended to be brought into the platform. If your example calendar widget becomes part of HTML, it would have a `::day` pseudo-element, not a `::part(day)` pseudo-element, because that's the way the platform works. Maybe that `::day` could also have a `::day(weekend)` syntax, but that could just as easily be `::day.weekend`. Let's give custom element authors the ability to create _custom_ pseudo-elements of a type that they determine, that look like, and act like, built-in pseudo-elements. And as I mentioned above, it also potentially gives them a way to create _native_ pseudo-elements as well. Something that the existing shadow part proposal can't do. Wouldn't it be useful to allow custom elements to define their own `::marker` for example? That just behaves in lists like any other marker? Or placeholder text that behaves, and can be styled, just like the placeholder text in native input elements right next to it?

Yes, exposing classes on top of pseudo-elements is something new (tho it's not a new _concept_, like part names is). There's also no reason that native pseudo-elements can't do the same. I expect once we start thinking in those terms we'll come up with several uses, e.g. `::error.spelling` and `::error.grammar` rather than `::spelling-error` and `::grammar-error`.

> 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").

You're already invented a third thing with the existing part name proposal, `::part(weekend):--selected` already uses three concepts, pseudo-element name, part name, and pseudo-class. `::--day.weekend:--selected` uses three _existing_ concepts, nothing new. There's also no semantic value to `::part`, just as there was no additional value in having `:state()`.

---
I think the disconnect we have is that you're thinking of this feature as "just a mechanism to select parts of a custom element, who cares how", and I'm thinking of it as a way of creating custom pseudo-elements (and explaining the built-in ones).



-- 
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4900#issuecomment-626072707 using your GitHub account

Received on Saturday, 9 May 2020 00:18:14 UTC