Re: [csswg-drafts] [selectors] Declarative custom `:state()` states (#12502)

> I was thinking that `:state()` would be paving the cowpaths, but if so many people are thrown by it, then it's clearly not a good option.

I have been waiting a long time for a proposal like this to land. I think the challenge a lot of people have with "state" is the connotation in the overlap with other languages. I believe that some people are reading it as the setting of state on document nodes, rather than the setting of styles, based on the state of document nodes (example of that, below). I think even an `:is-state(x)`, `:has-state(x)`, or `:matches-state(x)`, even if just parsed and read as an alias for `:state(x)`, would address some of the selector-based portion of it. That, and/or an education campaign. I'm partial to `:matches(x)`, but you can call it literally anything that won't trigger a visceral reaction, and I will be completely on board.


> > Would there be any means of nesting queries (media / container / style) inside of these declarations, or would it make resolving the tree too unwieldy?
> 
> ... I was thinking of it as a simpler at-rule that only takes descriptors and was thinking we could use a similar design for custom media queries (which is also a goal) ... it also mostly solves [#6247](https://github.com/w3c/csswg-drafts/issues/6247) and a bunch of other use cases. I’m not sure we have precedent of at-rules that can nest conditional rules but not regular rules, [@tabatkins](https://github.com/tabatkins) would know.

If it's unprecedented and unlikely to budge, soon, I am more than happy to live with the L1 you initially put forth. That on its own would be a great start (nomenclature misunderstandings aside). But I look at the conditional assignment of the matching selectors, even if it was done through different syntax, or if you could only set an internal variable, and assign it to the matches at the bottom... whatever mechanism works efficiently, and in a simple to teach/maintain/etc way, and I look back at the 2010s and responsive web monstrosities that could have been turned into hundreds of CSS lines, instead of thousands, if this alias, query-nesting, and `:has` had been around at the time. With all of that said, and with things like `if` and functions being worked on, I am really eager to hear reasons that the nesting couldn't / shouldn't be considered and / or included.

> I don't understand what issue you're describing. Is the worry that authors may create a
> 
> @state focus {
>  /* ... */
> }
> that would override your component's? If so, note that (as [@seanmay](https://github.com/seanmay) explained) in the proposal these states **cascade**, so no CSS can ever _remove_ a state set via either another CSS rule, or JS, it can only add states. So yes, in case of naming conflicts, _other_ elements may also have that state (or your WC, if it matches any author-defined selector _as well_), but I can't think of a case where that would be an issue?

I can't speak for others, of course, but given the misunderstandings around the terminology, and the questions around state-setting, I think some people are taking it to mean that these selectors would actively be changing the state of DOM nodes, which would be reflected in the behavior of their JS.

Forgetting WC, and just assuming Element State already existed, the smallest example I can think of, that might reproduce the concern I believe people are having, might be something like this:

```html
<!-- Benevolent CSS, HTML, and JS, below -->
<link rel="stylesheet" href="form-style.css">
<form >
  <!-- Form content -->
  <input type="text" ... >
</form>
<script type="module" src="form-behaviour.js"></script>

<!-- Malevolent State-setting CSS, here -->
<style>
/*
  by declaring the below state, I make it impossible to submit forms or modify inputs,
  via user-action, or JS, because the spec suggests that I am *adding* states in a cascade,
  where the CSS matches apply, even if DOM and JS states no longer do...
  ergo, all forms, inputs, buttons, and textareas will be :disabled if they ever have focus
*/
@state disabled {
  matches: form:focus, form:focus-within, input:focus, textarea:focus, button:focus;
}
</style>
```

I'm not suggesting this is the exact thought process of any given individual, but I think I understand where some of the alternative readings are coming from, and I think this highlights where the logic would conclude, if it were to work in the way this alternate reading might suggest.

-- 
GitHub Notification of comment by seanmay
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12502#issuecomment-3094906027 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 21 July 2025 00:16:24 UTC