search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 652 forks source link

[selectors] Custom state pseudo class proposal #4805

Open atanassov opened 4 years ago

atanassov commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

How does this relate to https://github.com/w3c/csswg-drafts/issues/3431?

css-meeting-bot commented 4 years ago

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/w3c/csswg-drafts/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 commented 4 years ago

(subscribing myself to this issue)

fantasai commented 4 years ago

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 commented 4 years ago

Web Components f2f minutes here: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-602756608

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:

Points against:

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 commented 4 years ago

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

tabatkins commented 4 years ago

Whoops, yeah, I posted this to the wrong place. I'll move it appropriately.

josepharhar commented 1 year ago

An important comment was to make sure this feature can handle enums, not just boolean states.

I found a bunch of discussion including what looks like a concrete proposal here: https://github.com/WICG/custom-state-pseudo-class/issues/4#issuecomment-632556585 What does everyone think?

css-meeting-bot commented 1 year ago

The CSS Working Group just discussed [selectors] Custom state pseudo class proposal, and agreed to the following:

The full IRC log of that discussion <emilio> live*
<emeyer> fantasai: Should we be taking this up and drafting it into Selectors 5, or are we waiting to colelct interest or information?
<emeyer> TabAtkins: Based on our last comment, we’re not super interested in implementing
<emeyer> fantasai: I’ll untag it from mobile 4
<fantasai> s/mobile/selectors/
<emeyer> Rossen: Anyone else interested in taking this up?
<emeyer> TabAtkins: The open question is about to do with non-booleans
<Rossen_> explainer - https://github.com/WICG/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md
<jarhar> I made a HTML PR here: https://github.com/whatwg/html/pull/8467
<emeyer> TabAtkins: Okay, we actually should take that up. We could merge it into selectors.
<emeyer> fantasai: We should merge it into 5, not 4.
<TabAtkins> https://wicg.github.io/custom-state-pseudo-class/
<emeyer> Rossen: The resolution is we’re going to take the boolean part into selectors 5.
<emeyer> TabAtkins: Joey reminded he has an issue to put this in HTML. We should mention it in selectors but point over to HTML.
<emeyer> RESOLVED: merge a limited version of https://github.com/WICG/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md into Selectors 5
<emeyer> github-bot take up https://github.com/w3c/csswg-drafts/issues/6867
josepharhar commented 1 year ago

I started a PR: https://github.com/w3c/csswg-drafts/pull/8213

emilio commented 1 year ago

Agenda+ as per @josepharhar's request, re. the discussion about :state(foo) and :--foo

emilio commented 1 year ago

Some of that discussion is in https://github.com/whatwg/html/pull/8467, ftr.

josepharhar commented 1 year ago

context: I don't have an opinion about :state(foo) vs :--foo, but @rniwa thought that we should be doing :state here: https://github.com/whatwg/html/pull/8467#issuecomment-1648866722 There was also a previous discussion/resolution in the CSSWG here: https://lists.w3.org/Archives/Public/www-style/2020May/0017.html

Loirooriol commented 1 year ago

8094 points out that :--foo is also proposed for custom selectors, e.g. https://drafts.csswg.org/css-extensions/#custom-selectors has this example:

@custom-selector :--heading {
  expansion: h1, h2, h3, h4, h5, h6;
}
css-meeting-bot commented 1 year ago

The CSS Working Group just discussed [selectors] Custom state pseudo class proposal, and agreed to the following:

The full IRC log of that discussion <dael_> jarhar: I was working on getting this spec. Has :-- custom name syntax. Suggestion was :state instead of :-- for custom name. Turns out there was discussion in 2020
<dael_> jarhar: I don't have a strong opinion. I wish [missed] was here to state his case.
<jarhar> https://lists.w3.org/Archives/Public/www-style/2020May/0017.html
<dael_> jarhar: Previous resolution minutes ^
<dael_> astearns: Whatwg issue sounds like the idea is that it's more consistent with :part
<dael_> fantasai: oriol posted ac omment that :--was discussed for another kind of custom selector?
<fantasai> https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1662763534
<dael_> TabAtkins: Yeah. For like saying :--heading that was eq. of h1, h2 etc. Having the clash isn't ideal, though doable
<dael_> astearns: Always favor a name over ascii gibberish to make it easier to see what you're trying to do. not a strong opinion
<dael_> TabAtkins: Looking at the discussion where we decided, looks like everybody was unenthusiastic. If we decide to revert to :state I think that's fine
<dael_> TabAtkins: Counter argument was from plinss who wanted it not to be too distinct. The --makes it look like a normal pseudo class. I don't have a big opinion
<dael_> astearns: We could resolve to change to :state which makes it easier to get through whatwg. plinss can raise a new issue if he chooses
<dael_> fantasai: I think it makes more sense. We use --names when declaring, but not when pulling information from another system. Makes sense to not use -- for this case from what I understand it to be
<florian> +1
<dael_> astearns: Anyone want to wait on a resolution to make sure plinss is on board?
<fantasai> seems more consistent with ::higlight() also
<dael_> astearns: Objections to changing from -- to state
<dael_> RESOLVED: Change from -- to state
<dael_> astearns: Thanks jarhar
josepharhar commented 11 months ago

The :--foo syntax has been shipping in stable chrome for some time now, with a usecounter at 0.03%: https://chromestatus.com/metrics/feature/timeline/popularity/3796 I'm going to send an intent to deprecate for the old syntax with a plan to replace it with the new syntax, but I am concerned that my proposal to change the syntax may be rejected. I will post updates here. @rniwa @annevk

annevk commented 8 months ago

The HTML side of this has merged. But it also needs to be added to Selectors for parsing purposes. Semantics can be left to the host.