[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

[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/w3c/csswg-drafts/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/w3c/csswg-drafts/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/w3c/csswg-drafts/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