[css-shadow-parts] confirm browser support

[fergald]

I am planning to implement the ::part() half of the shadow parts spec in Blink. In order to send an Intert To Implement for this (as an experimental feature), I need to know what support there is from other browsers. My understanding is that is that there is broad support for the basics of ::part from supported by Edge, Safari and Firefox. It would be very helpful if you could confirm this here. Thanks.

@travisleithead @SmauG @rniwa

[hayatoito]

Thanks @fergald

@travisleithead @SmauG @rniwa
Could you help @fergald to know other browser's position about shadow parts spec?

I think the details of the spec don't matter here. We can fix the spec if something in detail is wrong. What matters here is that we can have a rough consensus that shadow parts spec's approach is worth to implement as an experiment, given that we abandoned /deep/ combinator.

[hayatoito]

This explainer, https://meowni.ca/posts/part-theme-explainer/, would be helpful to understand the motivation.

[hayatoito]

cc-ing: @tabatkins just in case.

[rniwa]

Apple supports the general idea of ::part and ::theme but not necessarily specifics of the current proposal.

[hayatoito]

I guess we notified the wrong smaug. We are sorry for that.
@smaug---- should be correct.

[smaug----]

@emilio @dbaron

[emilio]

I feel like the problem it tries to solve is valid, but the general mechanism
seems somewhat hairy.

In particular (maybe I misread how it works), doesn't all the part-forwarding
stuff mean that a ::part(..) selector matches differently depending on which
scope the selector is declared? Or should ::part(confirm-label) match even
if such selector is in the <x-button> component, as long as it's nested in a
<x-panel> component (using the spec examples)?

Anyway, personally I think Mozilla should take a similar position to Apple here, of
supporting the general idea but not any specifics, but I opened mozilla/standards-positions#59 to get a proper official position here.

[fergald]

Yes, the part forwarding stuff does mean exactly that as far as I can tell. The Chromium design doc is here

https://docs.google.com/document/d/1eFekJxcNlkKHN2BwFwiwv6FoLrlRnuct_TGB2cKomW8/edit#heading=h.6je7wsyqhc05

and discusses this a bit.

[rniwa]

We don't want any nested shadow boundaries to be automatically crossed. If a component chooses to expose its internal as a part, it should have the opportunity to make that decision.

Having said that, we can provide a mechanism for a component to expose its inter-component's part as its own part.

[tabatkins]

In particular (maybe I misread how it works), doesn't all the part-forwarding
stuff mean that a ::part(..) selector matches differently depending on which
scope the selector is declared?

No, there's nothing scope-specific about it at all. Could you point to what gave you that impression, so I can fix it in the spec? The parts that an element exposes are just a part of the element's API, like its class list or its ID. Each shadow host just has a parts map, which maps part names to a list of elements (either from its own shadow tree, or a descendant tree if they're forwarding).

Anyway, personally I think Mozilla should take a similar position to Apple here, of
supporting the general idea but not any specifics, but I opened mozilla/standards-positions#59 to get a proper official position here.

Directing this towards both Moz and Apple: this isn't a useful position to take. :/ We're currently proceeding in implementation on the assumption of support, based on previous statements from both of y'all's companies. "Like the idea, don't know about any details" means you don't like the spec and don't want us to implement, right? Because if we do implement, things'll gradually freeze, so you better make sure all the details you're unsure about are indeed something you'd like to see.

[emilio]

Directing this towards both Moz and Apple: this isn't a useful position to take. :/ We're currently proceeding in implementation on the assumption of support, based on previous statements from both of y'all's companies. "Like the idea, don't know about any details" means you don't like the spec and don't want us to implement, right? Because if we do implement, things'll gradually freeze, so you better make sure all the details you're unsure about are indeed something you'd like to see.

I want to insist that that was a personal position, not nothing official, fwiw. I don't have the cycles right now to be able to review the spec as carefully as it deserves, and thus I don't want to say I support specifics that may have implications that I haven't actually grasped fully.

No, there's nothing scope-specific about it at all. Could you point to what gave you that impression, so I can fix it in the spec? The parts that an element exposes are just a part of the element's API, like its class list or its ID. Each shadow host just has a parts map, which maps part names to a list of elements (either from its own shadow tree, or a descendant tree if they're forwarding).

That means that selectors in an descendant shadow tree that specify a part that that is forwarded from an outer shadow tree should match, is that right? (See my example in that comment).

If so, that seems reasonable to me, but that is not in the specification (nor it seems the most obvious interpretation, given @fergald seems to have read the spec the same way I did). I can file an issue for that if you want.

[tabatkins]

Ah, I see what Fergal said. Looked at from the perspective of the element that ::part() refers to, sure, it can have different names. They're still not about scope, tho, they're about what shadow host you're drawing it from. The argument to ::part() is entirely a function of the originating element of the ::part() pseudo - the shadow host that has a parts map. The element that the pseudo points to has no choice in the matter.

That means that selectors in an descendant shadow tree that specify a part that that is forwarded from an outer shadow tree should match, is that right? (See my example in that comment).

Can you restate the example with some markup? It's not clear to me from your previous post what exact scenario you're asking about here.