- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 18 Mar 2026 16:27:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] pseudo selector to match forms ValidityState`, and agreed to the following: * `RESOLVED: use proposed functional syntax for invalid and user-invalid` * `ACTION: open issue on specificity for functional invalid and user-invalid` <details><summary>The full IRC log of that discussion</summary> <JoshT> lwarlow: idea behind this is CSS doesn't provide everything you want to style stuff like error boxes based on validity of form controls<br> <JoshT> ... exists some existing selectors for in-range and out-of-range<br> <JoshT> ... but that is limited view<br> <JoshT> ... in HTML, there are various attributes for constraints<br> <JoshT> ... idea is to bring those to CSS<br> <JoshT> ... discussed whether to add lots of pseudo classes<br> <Rossen> q?<br> <JoshT> ... could make invalid and user-invalid functional, take a keyword that maps to validity state<br> <Rossen> ack kbabbitt<br> <kbabbitt> q-<br> <TabAtkins> seems reasonable to me<br> <fantasai> same<br> <TabAtkins> (the functional form)<br> <TabAtkins> belongs in Selectors<br> <JoshT> lwarlow: if we spec this, would it go in selectors or css-forms for now?<br> <fantasai> +1 to functional form<br> <JoshT> Rossen: let's resolve first. people seem convinced<br> <emilio> q+<br> <davidjmarland> functional gets my vote. reduces confusion that `div:too-long` might do something<br> <Rossen> ack emilio<br> <JoshT> emilio: how does this interact with horistics? normally set when user changes control<br> <JoshT> ... does the interaction resolve on failure in some way?<br> <JoshT> fantasai: right now, heuristics on when to do matching. but this would narrow it down to show you if it's invalid in a particular way<br> <lwarlow> q+<br> <JoshT> emilio: should a functional user-invalid be invalid in a particular way or an action results in the error?<br> <JoshT> fantasai: equiv to user-invalid + invalid in a particular way<br> <JoshT> emilio: could we instead expand :invalid?<br> <JoshT> lwarlow: i don't think we need both. we could expand one<br> <Rossen> ack lwarlow<br> <JoshT> ... but for ease of developers, making it work on both seems easy to implement<br> <JoshT> fantasai: requiring just for a specific thing is not great, plus messes with specificity if you add one more pseudo<br> <JoshT> emilio: i'm OK with it. but would it be useful to have an extra ???<br> <JoshT> ... and do we want the functional version to be more specific than non-functional<br> <JoshT> fantasai: pseudo-classes have the same specificity of a class<br> <fantasai> s/have/typically have/<br> <lwarlow> q+<br> <bramus> +1 to more specific<br> <JoshT> emilio: there are exceptions. I'm OK with that. but it feels like it might want to be more specific<br> <Rossen> ack lwarlow<br> <JoshT> lwarlow: it being more specific might be useful<br> <castastrophe> +1 to consistency, not more specific<br> <JoshT> ... you might have an overall style that's invalid, and you want to override with a more specific type of invalidity<br> <romain> +1 to not more specific<br> <JoshT> ... but I'm fine either way<br> <romain> adding specificity is easier than removing it<br> <castastrophe> I feel like irc needs like a polling gui 🤣<br> <JoshT> ... we could answer that with prototyping<br> <fantasai> POLL: Should the argument add specificity?<br> <fantasai> (yes/no)<br> <lwarlow> Yes<br> <romain> no<br> <bramus> yes<br> <TabAtkins> no<br> <castastrophe> no<br> <JoshT> no<br> <davidjmarland> no<br> <dshin-moz> yes<br> <lea> no<br> <ChrisL> abstain<br> <astearns> abstain<br> <miriam> yes<br> <hoch> abstain<br> <kbabbitt> no<br> <lea> q?<br> <JoshT> Rossen: poll favours no<br> <JoshT> fantasai: this is not just a bikeshedding issue so I don't think we can call it based on this<br> <JoshT> ... I think the question needs more consideration<br> <lwarlow> Follow-up sounds good to me<br> <castastrophe> +1 fantasai, seems like a needs more data result<br> <JoshT> Rossen: That's also where I was going. We can open a follow up issue in the specificity<br> <JoshT> PROPOSAL: use proposed functional syntax for invalid and user-invalid<br> <lwarlow> +1<br> <JoshT> RESOLVED: use proposed functional syntax for invalid and user-invalid<br> <lea> Re:specificity, to elaborate on my "no", conceptually I agree it should add specificity, but currently, specificity is a pretty blunt instrument. How would it add specificity? By adding to the type selector count? That would be quite unprecedented<br> <JoshT> Rossen: does this go into selectors, where it is currently?<br> <JoshT> ... or does it go to css-forms, or anywhere else?<br> <dbaron> I think I also lean no on specificity<br> <TabAtkins> Prefer Selectors<br> <TabAtkins> Agree, Lea. And while "being more specific *somehow*" does make some sense, in practice I think it's just fine to rely on ordering for this - generic styling will go first, specific styles will go after.<br> <JoshT> ... we will leave in selectors for now<br> <TabAtkins> I don't want to get into "one iota more specific"<br> <JoshT> ACTION: open issue on specificity for functional invalid and user-invalid<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1525#issuecomment-4083878134 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 March 2026 16:27:47 UTC