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

> Should setting state be a concern of CSS?

I don't believe that this is a matter of setting state, any more than the following are setting state:

```ts
//.ts
type Heading =
  | H1 | H2 | H3
  | H4 | H5 | H6
  | ({ role: "heading" } & {});

// or .js
const attributeMatches = (attr, value) => (el) =>
  el.getAttribute(attr) === value;

const isHeading = el => ([
  isH1, isH2, isH3,
  isH4, isH5, isH6,
  attributeMatches("role", "heading")
].some((test) => test(el))); 
```
Neither the `Heading` type, nor the `isHeading` function are setting state.

If I am reading the proposal correctly (and please correct me if I am wrong, @LeaVerou) the term "state" here is much more like a reflection of "state of being", rather than "I am changing the value of the text in the div, and deselecting the user's form input".

Perhaps the word is too overloaded to use. There are a lot of overloaded terms as you adopt more languages.
I would imagine a `: matches(any-heading)` would be idoomatic... except that `: matches` is the former name of `: is` and can be semantically (linguistically, not programmatically) confused with the same. But the hangup here is the English word, not the behavior, to the best of my understanding.

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


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

Received on Saturday, 19 July 2025 02:50:19 UTC