[selectors] Custom state pseudo class proposal

[atanassov]

Based on recent TAG review of the proposed Custom State Pseudo Class feature it was surprising that this topic hasn't been discussed with the csswg yet.

Given Chrome has an intent to ship this feature it will be helpful for us to at least discuss it.

[SelenIT]

Given that this proposal seems to be custom-element-specific, probably [css-shadow-parts-1] would be a better place for it than [css-pseudo-4]?

[heycam]

it was surprising that this topic hasn't been discussed with the csswg yet

Procedurally, is it incumbent on us as CSSWG members to notice specifications developed in WICG that impact CSS, and to then bring them up for discussion here to provide feedback in that venue?

[tabatkins]

No, it's supposed to be part of our process to rope in appropriate experts, and in this case would absolutely be a "file an issue in CSSWG" sort of thing. Failing on our part, sorry about that; I didn't realize we were at the ItS stage yet.

[smfr]

How does this relate to #3431?

[css-meeting-bot]

The CSS Working Group just discussed Custom state pseudo class proposal.

The full IRC log of that discussion

<dael> Topic: Custom state pseudo class proposal
<dael> github: https://github.com//issues/4805
<bkardell_> q+
<dael> Rossen_: This is about a custom state pseudo classes. Being worked on in WICG.
<dael> Rossen_: Ready to be shipped by chrome in I believe 82 which is 4 or 6 weeks from now-ish. I don't know exact dates for when it's on by default but feature will be spread and enabled for large amount of users
<dael> Rossen_: Some of TAG feedback was around shape of API and it only allows bool state checks
<dael> Rossen_: This was acknowledged by feature authors but dismissed as can live with for now
<Rossen_> q?
<dael> Rossen_: Talking about with WG is I looked through past feautre discussion and didn't see this covered. Before it's too late wanted to give air time with group and gather if any reservations or concerns
<dael> bkardell_: I wanted to mention that a whole bunch of people from WG have been involved in design and discussion. This is like constructable stylesheets where that's the case and it's hard to know right venue for discussion. Given there's history and thought would it make sense to present a bit about it?
<dael> Rossen_: Sounds great. If you want to take a couple minutes and frame the feature and intent it would be great. Are you the right person or should we ask somebody else
<dael> bkardell_: I suppose I could, but TabAtkins is on and can do a good job
<dael> TabAtkins: Been a bit since I looked at it. Core deal is custom elements sprout a new dom token map that takes strings. Can match with :state you say :state and it can match
<dael> TabAtkins: Reason is you want to expose internals selectors can match w/o manipulating visible dom. shadow dom is a lot exposing attributes without impacting outside. Design is canted toward that direction wehre it's bool token or not. Future room for name and value but right now it focuses on class
<dael> bkardell_: Not unlike :fcous, :hover internal states
<Rossen_> q?
<dael> TabAtkins: That's what it's meant to be able to expose. Internal tates like that. It could be done via a class but b/c it's UA it's pseudoclasses
<emilio> q+
<Rossen_> ack bkardell_
<dael> Rossen_: Questions here. Is the current proposal in it's form going to preclude addition of anything other than bool?
<dael> TabAtkins: No. Syntax is easily extensible to allow it when we want to do it.
<dael> Rossen_: And this was major concern raised and attempted to be debunked in issue I linked to. It was that there are no interesting bool states and no need to feature creep. Checkbox has 3 states and things like that. As long as non-bool aren't precluded in the future this is not too bad
<bradk> So, not really for things similar to ‘nth-child()’ ?
<dael> TabAtkins: Correct. Nothing would prevent that in the future
<plinss> q+
<Rossen_> ack emilio
<dael> emilio: This is for top level custom element, right? Find it weird it works for custom and not regular elements. Exposing states from parts they must be custom or different like tokens. It's . abit ugly
<dael> emilio: Let's say you want to expose a state in a component. It would only work if the part is a custom element. If you don't want custom for example if it's SVG you need part elements instead using :state which is meh. Why doesn't it work for all elements?
<dael> TabAtkins: Main reason is...eaiser to put this structure on the root instead of arbitrary elements. You articulate a good use case for parts of shadow element exposing states. Ordinary element can just use class and multi ways for same thing is weird. Leads to there is a way to do bool state in parts which is add more part names. parts are basically classes and states are basically classes
<dael> emilio: Could use same arguement to say top level element can use class
<fremy> q+
<dael> TabAtkins: But then if you use class component messes with outer page visible section which we try and avoid, espeicially with things like aria stuff we're trying to mess with. Exposing controls without visible extra attributes is the goal of shadow dom. That's what's different for class. Doesn't apply to state vs part
<dael> emilio: Okay, I can buy that. A bit weird to have 3 ways to attach bool token to element
<dael> bkardell_: If you read the issue there is a desire to have parity where we could do the same thing on focus and hover type elements. They work today and it would be handy to have a custom element where you can have state. I agree this isn't solving all prblems like this but I think the idea here is limit the scope
<dael> plinss: Two concerns
<Rossen_> ack plinss
<dael> plinss: I accept that majority of use cases are bool. There are examples of non-bool state. Happy it's extensible in css but JS api is not in .away that's dev friendly. There's already things that are map-like but we don't use map api. I'd like work done on api to make it more future proof. I'd like it to be able to handle non-bool cleanly
<AmeliaBR> q?
<dael> plinss: Second is should it be :state or :--[name] and really make it a custom pseudoclass and not an odd pseudoclass called state
<dael> TabAtkins: Not a bad suggestion. Alright.
<dael> plinss: If we change this to :--[name] I'd like to see part do the same for consistency. For syntax they should be a unit. I have other issues with :part but that's sep. convo
<bkardell_> I have brought this up in the past, I think :--name is more interesting, but I think the argument is made this is diff and specifically about a kind of parity
<dael> fremy: I think plinss brought a good point. Thinking similar. I understand TabAtkins arg about need for aria mapping not changing with setting attribute. But we could do same as :part Maybe we want JS API to be able to remove values not in attrbute
<emilio> q+
<emilio> ack fremy
<dael> fremy: I don't understand why we need :State and :part. Why can't we have same API that applies on the same thing as :part. Maybe it's a point to think about
<bkardell_> can I ask how is it the same as parts, it seems not the same to me... ?
<bkardell_> +1 what peter said
<dael> plinss: That ties into my issues about part. I think it's valid to have custom state and custom part. How part is now is like a pseudoclass and I"d like to be a pseudo element thing. Then it makes sense to have them as 2 things
<bkardell_> and to what emilio said :)
<dael> fremy: Can query multiple part things, but I was going to mention that [missed]
<dael> fremy: It does make sense, fine.
<dael> TabAtkins: Switching to ::-- we're switching to tag name not class name. Requires if people to decide if it's class name or part name like. Maybe shouldn't expose to authors.
<dael> TabAtkins: Can we put this in GH repo? This is good.
<bkardell_> q+
<emilio> ack emilio
<dael> plinss: I raised this is tag review and didn't get a fair shake i felt. It would be good if it's addressed. You and I can haggle part separately. this is about state for now
<dael> Rossen_: Given we're 30 min into call I think reasoning and motivation to put this in group is achieved. Raising awareness and getting right people while we can provide feedback and engage with folks getting ready to ship.
<dael> Rossen_: I see two people on queue. I'd prefer to move on unless emilio or bkardell_ want to bring something pressing
<emilio> Rossen_: was already out of the queue ;)
<Rossen_> ack bkardell_
<dael> bkardell_: one thing before it's lost. Of course I 100% agree with plinss with wanting to see :: for custom pseudoclass and pseudostate.
<dael> bkardell_: Question worth getting plinss and group thought is if that's the same as this or if this is discrete and about custom elements. It's been portrayed to me that they are different. Encapsulating state is a different things then a general purpose pseudoclass
<dael> bkardell_: Interesting to think about
<dael> Rossen_: Let's continue in linked gh and WICG.
<dael> Rossen_: We'll also take this is TAG
<bkardell_> s/::/:--

[FremyCompany]

(subscribing myself to this issue)

[fantasai]

CSSWG minutes are here: https://lists.w3.org/Archives/Public/www-style/2020Mar/0009.html
An important comment was to make sure this feature can handle enums, not just boolean states.

[tabatkins]

Web Components f2f minutes here: WICG/construct-stylesheets#45 (comment)

Overall there's consensus on implementing document.adoptedStyleSheets as an ObservableArray.

There also appears to be consensus on moving document.styleSheets to a (readonly) ObservableArray subclass, so it'll sprout the same array methods.

The contentious question that couldn't be resolved on the call, and which is being left for us to decide, is whether direct assignment of an array is allowed; that is, whether document.aSS = [ss1, ss2]; works or throws.

Points in favor:

• Other mutating list-like APIs on the platform allow direct assignment, or plan to: el.classList allows it; Typed OM array-likes intend to allow it; various CSSOM APIs (CSSMediaRule.media and CSSStyleRule.style effectively allow it, via their [PutForwards] extended attributes that allow setting to a string to replace the associated lists).
• Seems weird to disallow direct setting, when there are other ways to replace the entire array (calling .splice(), or emptying the array and then .push()ing). Complex restrictions seem bad without strong reasons for them, as it means authors have to learn a more complex API boundary and can't rely on knowledge from elsewhere.

Points against:

• When subclassing a custom element, setting an array assumes that the superclass hasn't set any stylesheets itself; if it has, and you weren't aware of this, the subclass setting an array will wipe out the superclass's sheets. If the subclass instead just always used .push(), it wouldn't clobber anything.
• The setter will consume the array, not use it; document.aSS will have equal contents to the array you set, but not equal identity (it'll return an ObservableArray object, not the iterable the author assigned). This is distinct from how userland array-valued properties tend to work, and might be weird.

---

I'm at this point strongly on the "assignment should be allowed" camp. In particular, the first point against was most vociferously argued, and I think it's absolutely something we should reject. The footgun is not "clobbering the superclass's styles", it's subclassing at all. It is exactly as dangerous to naively clobber the superclass's styles as it is to naively append to the superclass's (unknown) styles; both are equally likely to screw up your component with parts not getting the styles they expected.

In addition, this problem is common to every single aspect of the superclass, not just styles. Literally anything the subclass does might, if it's not aware of what the superclass is doing, screw up what the superclass is doing. Adding a special-case restriction to try and make subclasses less likely to screw up this specific case won't materially improve the situation. Even if it weren't the case that I think .push()ing is just as dangerous (so there's no way to reduce the risk anyway), increasing the complexity of the overall API surface for an insignificant improvement in safety is generally a bad tradeoff, I believe. We've made the judgement that similar sorts of tradeoffs aren't worthwhile elsewhere in CSS.

---

So anyway, Agenda+ to get a final decision on this. I secured a promise from Apple to ensure a relevant person attends the CSSWG call, so hopefully this can be bumped for this week's agenda?

[othermaciej]

Constructible Stylesheets seems like a separate issue and separate spec from Custom State Pseudo Class, perhaps it merits a separate issue?