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

[dbaron]

I had some comments in both mozilla/standards-positions#59 and w3ctag/design-reviews#230. I think my biggest concern is that ::part() and ::theme() feel too related to each other to have completely unrelated names. (::theme() almost feels like a combinator that could be attached to ::part().) I'm also a little concerned about the complexity of the part-forwarding microsyntax. I had one suggestion, although I don't know think it actually helps very much. I haven't had much time to dig in to the spec yet, though.

[emilio]

So, let's say I have nested components <x-foo>, <x-bar>, <x-baz> and <x-quux>, the last of which has a part="label" element.

For simplicity, all forward with the relevant name, that is, in x-foo, we have: <x-bar part="* => bar-*"> (did I get the syntax right?), in x-bar we have <x-baz part="* => baz-*">, and so on.

That means I can target the label from the outer scope like:

::part(bar-baz-quux-label) { /* stuff */ }

Right?

My question is, would that same selector match the same label, even if it was declared in one of the inner scopes? I guess the intention is that it does not, and that's the bit that makes a ::part(..) selector depend on where the selector is declared / in which scope it does live. In particular, in the design doc linked by @fergald, this is the problematic condition (emphasis mine):

Having reached the scope containing the selector succeed if any of the names of the element in this scope match the name in ::part() component.

I'm not saying it's impossible to implement or anything like that, I just think that's a somewhat new requirement that deserves some thought. What should:

shadowRoot.querySelector("[part=label]").matches("::part(label)")

return?

What about:

shadowRoot.querySelector("[part=label]").matches("::part(bar-baz-quux-label)")

Does something like :host::part work, thus allowing you to style parts from inside the component?

[emilio]

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.

The issue is that ::part has multiple originating elements, depending on which scope are you matching from, if you allow forwarding.

[tabatkins]

My question is, would that same selector match the same label, even if it was declared in one of the inner scopes? I guess the intention is that it does not, and that's the bit that makes a ::part(..) selector depend on where the selector is declared / in which scope it does live.

It doesn't match, but that nothing do with scopes like you're implying. It's because, like I said in my previous comment, the part names are associated with the shadow host, not the element that the ::part() pseudo is pointing to.

The x-foo element has a bar-baz-quux-label part. The x-bar element has a baz-quux-label part. The x-baz element has a quux-label part. And the x-quux element has a label part. The fact that all of these parts end up pointing to the same deeply-nested element is irrelevant; they're completely independent facts associated with different shadow hosts.

shadowRoot.querySelector("[part=label]").matches("::part(label)")

This will be false - it's the shadow root's host element that has a "label" part, and will match ::part(label). And thus, since this selector is being run inside of the shadow root, and the host element is featureless, there's nothing you can put on the LHS of that pseudo-element that'll match. (You could write :host::part(label); that would be true.

(This is assuming that .matches() can ever return true when comparing elements and pseudo-element selectors; pseudo-elements that point to real elements is a pretty recent thing, and I don't know that this is well-defined. But it does make sense to me for this to work.)

shadowRoot.querySelector("[part=label]").matches("::part(bar-baz-quux-label)")

Since this is being run inside the x-quux's shadow root, apparently, there is no element that can match that selector even if you use :host (since the host element is x-quux, which doesn't have a "bar-baz-quux-label" part in its map).

The issue is that ::part has multiple originating elements, depending on which scope are you matching from, if you allow forwarding.

This is the "pseudo-elements that point to real elements are new" confusion I just mentioned. The originating element of a pseudo-element is the thing matched by the compound selector to its left. In ::part(), that's just the implicit *, but of course it can be more. All four of the ::part() examples you list are different pseudo-elements, each originating from a different host. They just all happen to point to the same element.

[emilio]

This is the "pseudo-elements that point to real elements are new" confusion I just mentioned. The originating element of a pseudo-element is the thing matched by the compound selector to its left. In ::part(), that's just the implicit *, but of course it can be more. All four of the ::part() examples you list are different pseudo-elements, each originating from a different host. They just all happen to point to the same element.

That's fair, though in practice no UA will / can implement it that way as far as I can tell.

So in practice, at least to the implementations I know (WebKit / Blink / Servo / Gecko), it imposes the requirement of knowing where the selector has been declared / where the rule comes from, so we can know which shadow root does it come from / which shadow host matches it.

Other question as I look more through this... Where do these rules fit in the cascade? After normal author rules? How do these interact with ::slotted, in particular where nested slots and forwarding interact? All those need to be well defined for the spec to be implementable.

[tabatkins]

So in practice, at least to the implementations I know (WebKit / Blink / Servo / Gecko), it imposes the requirement of knowing where the selector has been declared / where the rule comes from, so we can know which shadow root does it come from / which shadow host matches it.

I'm still not seeing this. The context of the selector has absolutely nothing to do with this; it's purely about which element the ::part is descending from. As I explained in your examples earlier, a given part name can match an element from inside (:host::part(bar)) or outside (x-foo::part(bar)) a particular shadow tree, which shows that the tree context has no relevance here. (It just happens that, due to the way we've restricted selectors and shadow trees, a given element is only directly reachable from certain contexts.)

If you store the part-name information on the target element, rather than the shadow host, then yeah, you'll need to store it as a (shadow host, part name) tuple, but that's still got nothing to do with the selector's context. ^_^

Other question as I look more through this... Where do these rules fit in the cascade? After normal author rules? How do these interact with ::slotted, in particular where nested slots and forwarding interact? All those need to be well defined for the spec to be implementable.

How selectors reaching across shadow trees work in the cascade is already well-defined by the Shadow DOM spec. Unless we specifically want some special effect, there is no need to define anything further.

[rniwa]

Here's one concrete feedback.

There should be no difference between closed and open shadow trees for ::theme. ::theme should always penetrate shadow boundaries. Otherwise, it defeats the primary use case of ::theme.

[emilio]

I'm still not seeing this. The context of the selector has absolutely nothing to do with this; it's purely about which element the ::part is descending from. As I explained in your examples earlier, a given part name can match an element from inside (:host::part(bar)) or outside (x-foo::part(bar)) a particular shadow tree, which shows that the tree context has no relevance here. (It just happens that, due to the way we've restricted selectors and shadow trees, a given element is only directly reachable from certain contexts.)

Ok, I think I see what you mean now, and I see how it can be implemented without caring about the context of the selector, thanks for bearing with me :).

I think CSSOM should probably not return true ever for something that contains a ::part pseudo, though. That means that if you do something like element.matches("x-bar::part(foo), you need to actually check it against all possible originating elements, which sounds somewhat annoying and special-case-y compared to how all other selectors work. But that's probably worth another issue.

[emilio]

I think CSSOM should probably not return true ever for something that contains a ::part pseudo, though. That means that if you do something like element.matches("x-bar::part(foo), you need to actually check it against all possible originating elements, which sounds somewhat annoying and special-case-y compared to how all other selectors work. But that's probably worth another issue.

Maybe this isn't even actually that bad... Anyway, will think more about it. Thanks @tabatkins :)

[tabatkins]

There should be no difference between closed and open shadow trees for ::theme. ::theme should always penetrate shadow boundaries. Otherwise, it defeats the primary use case of ::theme.

Interesting. I'd think that letting ::theme penetrate defeats the primary purpose of closed shadow trees. ^_^

I'll open a separate issue for this, tho.

[fergald]

Pinging this issue again. Chrome has implemented part and partmap attributes and ::part selector behind a flag. The spec is in line with chrome's implementation draft spec.

At this point I would like to gather any more feedback on the spec and the issues listed there and here

I will also solicit feedback from custom-element-using devs too and then bring the end result to a CSSWG conference call and move towards shipping it in Chrome.

The theme section of the spec has not had much attention, feedback is welcome on that but I am hoping to move forward with part without blocking on theme.

@hober

[fergald]

@dbaron you had some comments in other issues on naming and overlap between part and theme. I don't know how to capture them. Do you feel they are blockers for moving forward with part?

[rniwa]

The biggest blocker for us is #2411 We can't implement this without knowing the syntax for the content attribute and the semantics of IDL attribute.

[fergald]

Polling once more for vendor support. Spec has been updated quite a bit. I would like to take this to CSS-WG (perhaps next week).

Here's a list of things that I hope are resolved or can be resolve in WG:

• attributes are part= and exposedparts=. Some debate over naming of exposedparts ([css-shadow-parts] IDL for attributes #2414)
• IDL attributes reflect these as simple strings with .part and .exposedParts ([css-shadow-parts] IDL for attributes #2414)
• exposedparts syntax is "innerName outerName, sameName, ..."
• *-forwarding postponed pending feedback from users on need for it
• ::theme is postponed pending feedback from users on need for it

@rniwa @hober @annevk @tabatkins @domenic @FremyCompany @gregwhitworth @dbaron

[fergald]

So that's "outer1 : inner1, outer2 : inner2, same1, same2"?

[FremyCompany]

I think the javascript-compatible way is inner1: outer1 if I understand inner and outer as you do

[tabatkins]

Yeah. oldName:newName is how JS works:

const {foo: bar} = {foo: 1};
// same as:
const bar = ({foo: 1}).foo;

[rniwa]

Yeah, since it's called exportparts, inner: outer since we're exporting inner as outer.

[fergald]

OK, spec and explainer are updated to exportparts="inner : outer".

Here's a list of things that I'd like to confirm:

• forwarding is part of the initial version with exportparts="innerName : outerName, sameName, ..." ([css-shadow-parts] decide on forwarding micro-syntax for partmap #2411)
• IDL - none vs string vs map? Seems like "none, moving to map-like in the future" might be the preferred choice ([css-shadow-parts] IDL for attributes #2414)
• *-forwarding postponed pending feedback from users on need for it
• ::theme is postponed pending feedback from users on need for it

[rniwa]

As for IDL attribute, we feel very strongly that we should add a proper named setter to the IDL attribute. e.g. exportParts['inner'] = 'outer'. If not, we shouldn't add an IDL attribute at this point. Any IDL attribute proposal which involves string manipulation is simply unacceptable to us.

[fergald]

OK, unless someone else feels strongly, I will remove the IDL section entirely and leave it as an open issue.

[annevk]

I don't think we should add any new objects with named setters (i.e., objects that require proxies).

[domenic]

We can move the string reflection to an experimental section, and gather developer feedback in Chrome before marking it as having consensus. I'd encourage those who believe something more complicated would benefit developers to propose something concrete and find developers who would use it, in the same way.

Agreed on no more use of legacy named setters in IDL.

[tabatkins]

Also agree on no named setters. We have the maplike<> declaration for handling this in a much better fashion. (Otherwise, what's the behavior of creating a part named, say, __proto__? That's a valid CSS ident!)

I'm fine with there being no IDL attribute yet; getAttribute() suffices to get the string value.

[rniwa]

Sure, maplike<> would be fine too.

All that we object to is string IDL attribute.

[fergald]

I've added Agenda+ label to this. I think we have agreement on a minimal version. I'd like to confirm that and go ahead (specifying the parser and some other bits) without waiting for the F2F if we can agree on this on the call.

[rniwa]

I'd appreciate if someone could add the time slot here for this discussion once that's determined.

[fergald]

This is the 6th (final) item on the agenda this week, so I don't know what time it would occur at. Meeting starts at 12:00 pm, Eastern Daylight Time (New York, GMT-04:00).

[css-meeting-bot]

The CSS Working Group just discussed [css-shadow-parts] confirm browser support.

The full IRC log of that discussion

<dael> Topic: [css-shadow-parts] confirm browser support
<dael> github: https://github.com//issues/2368#issuecomment-429342082
<dael> astearns: Is TabAtkins on?
<dael> fergal: I'm here, but I was hoping TabAtkins would be.
<dael> astearns: Will you be at F2F?
<dael> fergal: No. I was hoping to have agreement before
<dael> astearns: Summarize agreement?
<dael> fergal: There is a draft spec. Agreement I believe we have is there will be no idl for this in initial version. Agreement on minimal version that's acceptable. We have naming right for everything. There will be a part= and exportparts= and syntax is colon sep inner and outer name
<dael> fergal: we postpone multiple parts with an *. Everything with theme is postponed.
<dael> fergal: But I don't know if anyone else on the call understands that
<dael> dbaron: Is that written somewhere?
<dael> fergal: It's in the issue. THat list is there.
<dael> dbaron: I see 50 or so comments. Is there one to look at?
<astearns> 20 days ago
<dael> fergal: Toward the bottom
<dael> fergal: From 15 days ago
<fantasai> fergal,is it this comment? https://github.com//issues/2368#issuecomment-426472596
<dael> Rossen: What's the urgency to agree before TPAC? Especially since you said you wanted names agreed to proceed?
<dael> fergal: No particular urgency, just that this has gone for a long time. I wont' be at TPAC
<dael> Rossen: Is this something TabAtkins can handle in F2F?
<dael> fergal: I think so. I don't know for use that [missed] is going to tpac
<dael> ??: He is
<dael> fergal: If there's no one on the call who was in the discussion it has to wait.
<dael> astearns: Summary is still useful
<dael> astearns: We'll let you know fergal what time at TPAC in case you can call in
<dbaron> s/[missed]/Ryosuke Niwa/
<dael> fergal: great
<dbaron> s/??/myles/

[css-meeting-bot]

The CSS Working Group just discussed this issue.

The full IRC log of that discussion

<myles_> ScribeNick: myles_
<myles_> ::people fuss with the AV setup::
<TabAtkins> https://drafts.csswg.org/css-shadow-parts/
<myles_> TabAtkins: we discussed shadow parts in the past, fergal_daly worked closely with rniwa to figure out hwo we can get a consensus solution on some details. It went well, made amny changes and feedback. Notable: we separated the naming of something as a part from forwarding something's parts up into your part namespace. They're now separate attributes. Chagned syntax of part forwarding to match JS syntax for desctructuring because it's the same. While it's
<myles_> eays to get confused about whch name does what in JS destructuring, \people only have to learn it once. wen're not exposing ssomethign new and novel. Functionality is the same - can expose chunks of shadow dom
<fantasai> s/eays/easy/
<myles_> can't do further structuring, can't grab a part of a part, unless it's exlicitly forwarded, can do before and after
<myles_> and other pseudoclasses
<myles_> there are still some discussion about theme
<myles_> the thing that automatically exposes your parts arbitrarily up so they can be used from anywhere. further discussion is ongoing but the core part, the part pseudo element and how to expose it appears to be reasonably agreed on by us and apple
<TabAtkins> s/before and after/::before and ::after/
<astearns> github: https://github.com//issues/2368
<myles_> rniwa: there is consensus on the github issue. the 1 contentious part is the IDL attribute. for now we can add itand move foward. one question is because the topic of whether par tapplies to jsut hte first elemtn or everything? For theme, clearly allt he elements with the theme should ge tthe style, not jsut the first one. so the discrepancy there might be confusing. but on tehother hand, the use cases are different it may be okay that only the first elmetn
<myles_> gets the first the styl
<myles_> TabAtkins: so it's treated like an ID?
<emilio> q+
<myles_> rniwa: it's a question. Let's say shadow root has 2 elements that have a part attribute, boht say part=foo. Sholud both get the style? If the model is users are exposing an element to to outside to style, then it should be just one element. but if hte model is more like the users define style for a part and the compoent takes it form the users and apply somewhere, then it akes more sense for multiple elements
<myles_> TabAtkins: imagine a to do app. you want to expose for styling all of the indiviaul to do items. You can give them the same part naem and style them all, it works like a class. If you can only do one, each item would need a unique name.
<astearns> ack emilio
<myles_> emilio: that's better. I prefer to style the style of elements to be independent
<myles_> emilio: validation could be tricky. When you insert an element with a part element, you have to look for hte same part naem elsewhere in the tree
<myles_> rniwa: that's fine.
<heycam> s/validation/invalidation/
<myles_> rniwa: it's just a question. i dont' know the answer.
<myles_> TabAtkins: the goal of the session is to confirm we hav rough agreement on the feature set. earlier there were more disagreement. so i don't think we're ready for FPWD now but we can adopt as official ED.
<myles_> astearns: i dont' remember if its an EN
<myles_> TabAtkins: it's marked as an ED>
<myles_> TabAtkins: so we're pretty good. comments?
<myles_> TabAtkins: please raise issues.
<myles_> astearns: i suggest - the issue is a monster issue with many sub issues. if there's anything remaining, please move it to new issues. It's impossible to read.
<myles_> TabAtkins: ok.
<myles_> TabAtkins: we did already
<myles_> fergal_daly: please use existin issues
<myles_> astearns: sometimes TabAtkins will move comments for people
<myles_> fergal_daly: i'll do that then.
<myles_> fantasai: what are you looking for before FPWD?
<myles_> fantasai: FPWD doesn't mean it's done. it' means it's rough
<myles_> fantasai: and we have consensus on the approach, but not details. We don't have to fix the issues
<myles_> TabAtkins: it coule be reasonable to do FPWD
<myles_> fantasai: if there are no major issues before FPWD and we all agree we want to do it, we should do FPWD
<myles_> fantasai: and continue work with more visibly public draft
<myles_> fergal_daly: should we take theme if we haven't decided on it?
<myles_> TabAtkins: i'd be okay.
<fantasai> s/theme/theme out/
<myles_> rniwa: it makes sense. we need to update the spec. the ED is outdated.
<myles_> rniwa: remove the theme and the IDL attributes
<myles_> fergal_daly: IDL is already out.
<myles_> TabAtkins: yes.
<myles_> TabAtkins: right nwo the only way to access parts is to ge tthe attrigbute using the standard dom api
<myles_> fergal_daly: is there controversary for adding IDL for part as opposed to part fowarding? That's useful for feature detection
<myles_> rniwa: no controversy. It's okay to epxose part IDL attribute.
<myles_> fergal_daly: okay i'll do that.
<myles_> fergal_daly: and leave otu the map stuff completely
<myles_> TabAtkins: it might be worthwhile to officially do FPWD in a few weeks.
<myles_> astearns: yes, i'd liek to see people sign off on the state of the draft before FPWD
<myles_> TabAtkins: ok
<myles_> fantasai: for extracting out the stuff we're not doing now, maybe throw that into L2
<myles_> TabAtkins: ok
<myles_> s/L2/Level 2/
<myles_> TabAtkins: we can incubte the theme attribute.
<myles_> astearns: other comments?
<myles_> rniwa: mozilla support?
<myles_> emilio: it's reasonable
<myles_> emilio: when peopel askfor feedbakc, the conclusion iwas it's worht experiementing. the current agreed on thing makes sense
<myles_> astearns: Edge signals?
<myles_> TabAtkins: Edge just agreed to do shadow dom, so we'll see you in 6 months
<myles_> astearns: next topic: i18n
<gregwhitworth> I said that we'll take a look at the proposal and provide feedback at a later date
<myles_> ::people cast around for short topics while we wait for i18n::
<myles_> jensimmons: there is an issue for renaming the AR unit
<myles_> jensimmons: it's in grid level 2

[fergald]

I've added IDL for .part (#2414) and given a full spec of the parser (#2412). Happy to get comments on either of those on the relevant issues.

Putting this on the agenda to make it FPWD. Any other comments etc welcome (on the relevant issues if they exist)

[usrtax]

any update for exportparts="*: *" ? seems no browser support it