If you write theme.json by hand in an editor with schema validation on, you may have spent months ignoring red underlines beneath perfectly valid style definitions. Responsive styles and pseudo-class states shipped as a feature in WordPress 7.1, but the JSON schema describing the file did not fully cover them. The code worked. The editor insisted it did not.
Several fixes landed in Gutenberg 23.8 and the schema now matches what the feature actually accepts. Update your tooling, reopen the file, and look at what is still flagged, because it is now considerably more likely to be real.
A dishonest schema is worse than none
This sounds like a trivial fix and I would argue it is not. A validator producing false warnings trains you to ignore warnings. Once you have learned to scroll past a red squiggle under a :hover block, you scroll past the genuine typo three lines below it too. The value of the fix is the signal coming back.
On pseudo-class states
WordPress 7.0 brought support for :hover, :focus, :focus-visible and :active directly on blocks and their style variations. That matters beyond convenience, because it moves interaction styling out of a separate stylesheet you maintain by hand and into the same file as the rest of your design tokens.
One warning, and it is the kind of thing that gets shipped without anybody noticing. :focus-visible carries an accessibility obligation rather than an aesthetic preference. If a client dislikes focus rings and you style it away to nothing, you have shipped a site that keyboard users cannot navigate. Replace it with something at least as visible, or leave it alone.
The opt-outs, and when to use them
Gutenberg 23.8 also added blockStatesEditingEnabled and responsiveEditingEnabled, which turn the editing controls for these features off.
These are genuinely useful on client work. If you have built a design system with defined interaction states and handed it to an editorial team, exposing per-block hover controls is an open invitation for somebody to build the one page that undoes the system. Turning the controls off keeps theme.json as the single source of truth without taking the capability away from you.
Whether to use them is a judgement about the team rather than about the code. A site you maintain wants them on. A site where the client genuinely expects to restyle things themselves probably does not.
