What pseudo-elements should be allowed after ::picker(select) ?

[nt1m]

@annevk points out there are very non-sensical combinations if we allow everything like ::picker(select)::picker(select) or ::picker(select)::part() and having the parser support them means we lose any feature detection opportunities in the future if that syntax turns out to be useful.

[annevk]

cc @josepharhar @mfreed7

[dbaron]

Per https://drafts.csswg.org/css-pseudo-4/#element-like all element-like pseudo-elements syntactically allow any other pseudo-element after them (just like elements do). Many of those pseudo-elements never match, just as for elements.

[annevk]

Is that useful for anyone though? Should supports then also claim support? What about getComputedStyle?

[gsnedders]

Per https://drafts.csswg.org/css-pseudo-4/#element-like all element-like pseudo-elements syntactically allow any other pseudo-element after them (just like elements do). Many of those pseudo-elements never match, just as for elements.

https://drafts.csswg.org/css-forms-1/#picker-pseudo doesn't define it as an element-like pseudo-element, though?

Thus it would seem the status quo is what https://drafts.csswg.org/selectors-4/#sub-pseudo-elements says:

Unless the corresponding sub-pseudo-element is explicitly defined to exist in another specification, pseudo-element selectors are not valid when compounded to another pseudo-element selector.

I can't see, following cross-references, anything that does explicitly define the sub-pseudo-elements to exist?

[josepharhar]

When I originally defined ::picker, it was a part-like (aka element-like) pseudo-element: #10865

Not sure when that part got removed, but I don't remember a discussion about it.

[gsnedders]

cc @tiaanl who added tests for this to WPT in web-platform-tests/wpt@134ef56

[annevk]

I do remember WebKit at least arguing for a consistent pseudo-element story for all controls. Which came down to some of them not being able to be element-like in certain aspects because they can’t all be. That still makes sense to me.

[dbaron]

With elements, we don't make h1::file-selector-button a parse error, even though ::file-selector-button only works on <input type=file>. Element-like pseudo-elements should just work like elements.

The reason we created element-like pseudo-elements was part of the compromise where we agreed not to create complex controls out of web components technology. If we had built them on web components technologies (such as ::part()), we would have been building on existing platform primitives and wouldn't have had the opportunity to litigate every tiny decision like this. Part of the reason for creating element-like pseudo-elements was to declare that some pseudo-elements would act like elements in many ways both because it is reasonable to do so and because it mandates that there be less process of debating every single aspect of their existence exactly like we're doing here. I think the compromise in #9951 has not been honored by the side that was against ::part(), and next time around we should just use ::part().

[annevk]

I don't think that's correct. #9951 (comment) notes the resolution I also remember. And then #10083 was opened to further clarify this new concept, but I don't think that had a lot of cross-browser buy in necessarily.

[dbaron]

The resolution that you link to clearly says that we want the new pseudo-elements to be as close to ::part() as possible. The reason I stated above is why that was, to me, an essential part of the compromise.

[annevk]

I think the key distinction made in the meeting but not captured there (and why we couldn't get a full resolution) is that we don't want details of the shadow root to leak through the boundary. And that to the extent possible, that these pseudo-elements would have roughly similar capabilities to those that are not necessarily backed by something the shadow tree (such as ::picker-icon) so you can shift implementation strategies and give web developers a reasonably consistent story that doesn't depend on internals.