I was trying to figure out a way to solve #1968, but I see no way to target all these elements effectively in a single CSS rule. It would be easy if the #states elements had a generic .has-states class and perhaps also a second class with the specific state per element case. So a .states-[state] class where [state] would be one of:
- enabled
- disabled
- required
- optional
- visible
- invisible
- checked
- unchecked
- expanded
- collapsed
- relevant
- irrelevant
- valid
- invalid
- touched
- untouched
- readwrite
- readonly
Perhaps also a .states-lvl-x class if possible (where x is the numeric level of how many parent elements the element in question has).
I would file a PR, but this touches the Field API and I am not even remotely ready for than yet, so I rely on somebody else to tackle this. Once implemented, I think it will be easy(ier) for me to sort #1968
Recent comments
Perhaps, these latest lines of random test failures can be considered in the meeting too?
December 18th, 2025 - Weekly Meetings
There are some test failures in the user module after merging in the latest commits. Randomly, only in one PHP version - and always a different one. See also this Zulip...
December 18th, 2025 - Weekly Meetings
Two issues would benefit from testing and code reviews; they've been around for a while and no takers. It would be a shame for these to miss the next releases. View Table Headings...
December 18th, 2025 - Weekly Meetings