theme.json schema: block level pseudo-classes for core/button & core/navigation-link

[yashjawale]

What?

Closes #81057

This PR whitelists block-level pseudo-classes in the theme.json schema for core/button and core/navigation-link only, by making the block-fallback schemas permissive so per-block definitions are authoritative.

Why?

Currently pseudo classes for core/button and core/navigation-link are flagged by IDE validators based on theme.json schema. However, the support for them was previously added & the schema should reflect the same but allowing those properties.

How?

The strict generic patternProperties fallback was overriding every block's definition, so pseudo-classes were getting rejected on all blocks (including the two that are supported). This PR excludes core/button and core/navigation-link from that fallback via a negative lookahead regex, leaving core/button untouched and adding explicit pseudo-class (+ -current) support to core/navigation-link in both the main and variation block styles.

Now only the two runtime-supported blocks accept :hover/:focus/:focus-visible/:active, while all other blocks correctly reject them — including third-party blocks, which continue to be validated against the strict generic fallback.

However, one caveat of this approach is that the negative lookahead must be kept in sync with runtime support. Any future block that gains pseudo-class support needs to be added to the lookahead (and its explicit definition expanded) for its pseudo-classes to validate.

Testing Instructions

1. Create a theme.json file with the sample data.

Sample theme.json

{
    "$schema": "https://schemas.wp.org/wp/6.8/theme.json",
    "version": 3,
    "styles": {
        "blocks": {
            "core/button": {
                "color": {
                    "background": "yellow",
                    "text": "blue"
                },
                ":hover": {
                    "color": {
                        "background": "red"
                    }
                }
            }
        }
	}
}

2. Swith the $schema property value to be schema file in this branch
3. Notice that validation warnings don't show up
4. Try switching out pseudo classes for incorrect ones to ensure they're flagged

Use of AI Tools

Assisted by DeepSeek V4 Flash via Opencode
All changes reviewed & tested manually.

[yashjawale]

Another approach would be to change regex of patternProperties from ^[a-z][a-z0-9-]*/[a-z][a-z0-9-]*$ to negative lookahead ^(?!core\/)[a-z][a-z0-9-]*\/[a-z][a-z0-9-]*$

Can work since all core blocks are already explicitly listed in properties. And then third party blocks will still hit the previous strick fallback stylesPropertiesAndElementsComplete

[yashjawale]

Update the PR to use a negative lookahead regex that excludes core/button and core/navigation-link from the generic patternProperties fallback instead of the permissive catch-all fallbacks used earlier.

With this third party blocks (or any other blocks that aren't explicitly listed) continue to get strict checking instead of falling through.

For more details of the previous approach view the previous version of the PR description.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: yashjawale <yashjawale@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: mrleemon <leemon@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ramonjd]

Looks like stylesBlocksCustomStatesProperties is no longer used?

[ramonjd]

Also, by deleting these we're losing the descriptions, i.e., "description": "Custom class-based block states using the '-' prefix. Each state supports style properties as well as the same pseudo-selectors available to the block.",

[ramonjd]

#/definitions/stylesBlocksCustomStatesProperties already had -current. Couldn't we have used it?

[ramonjd]

Actually, that orphaned definition still contains the original bug (stylesPropertiesComplete pins propertyNames), so whoever $refs it next silently reintroduces this exact issue.

[ramonjd]

Thanks for getting this PR open. I haven't tested it manually yet. A couple of things popped up:

1. Should we add some more fixtures to cover the changes for the E2E theme-schema.test.js?
2. I'm not sold on the lookups on the regex lookaheads. It's going to be a maintenance headache and maybe it can be done with additionalProperties which already means "keys not listed in properties"
3. The literal "-current" inside two propertyNames unions breaks the file’s convention of a *PropertyNames enum per selector group and duplicates the value.

It's hard to cover everything... so I got a draft alt PR up to illustrate:

• theme.json schema: fix block pseudo-classes and custom states #81209

[yashjawale]

Ah right... That looks a lot better
Since #81209 is more up to date, should I go ahead & close this one?

[ramonjd]

s more up to date, should I go ahead & close this one?

If that's okay, thank you for understanding and kicking this off! I'll close and move things over to the new PR #81209. 🙇🏻