Add supports for pseudo states on single block instances#76491
Conversation
|
Size Change: +1.77 kB (+0.02%) Total Size: 7.95 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 162ec39. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25771822458
|
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @onetrev, @davewhitley, @itsdavidmorgan, @le-sgs. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
BlockStyleControls renders the same 5 panels twice — once for default state, once for non-default. Since every panel already defaults selectedState to 'default', you can always pass it and render once: |
|
Every panel (color, border, typography, dimensions, background) has near-identical boilerplate: check selectedState, read from style[selectedState], create a state-scoped onChange, wrap the resetAllFilter. Can we extract a shared hook? |
|
Can the “Show state on canvas” toggle live inside the state dropdown rather than requiring its own SlotFill? |
|
Since |
d4e46a5 to
7639d4c
Compare
I think that's not the place for it (we will have other types of states such as current, breakpoints, etc, living in the dropdown), but I agree we probably could avoid the SlotFill |
In the end I did this but I couldn't get rid of the SlotFill entirely. I don't think the toggle should be inside the dropdown, and we can't have it in the inspector controls anywhere without another SlotFill. |
…layout.php and position.php
* Block Editor: Use config for block pseudo states * Block supports: Render pseudo states from config * Block Editor: Support nested block style state paths
…lockStyle hook. (#78141) Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: talldan <talldanwp@git.wordpress.org>
* Show block state badges in inspector * Move state control badges to separate component * Render state badges from global styles header * Derive active states in state badges * Use useToolsPanelDropdownMenuProps for block instance state control menu * Fix duplicate import
… is active (#78190) * Show global styles on the canvas for pseudo states when Show state on canvas is active * Use existing merge helper * Improve accuracy of useMemo deps
* Fix border styles for block instance pseudo states * Try adding !important to authored border-style rules * Revise/simplify PHP border fallback to inject declarations * Revert editor fallback border style changes for pseudo states * Compile border style fallbacks seperately to avoid setting !important * Add missing !important properties * Use existing cleanEmptyObject util * Update outdated comment
11bb2be to
9f4e1fe
Compare
There was a problem hiding this comment.
Giving my tentative approval (though I did contribute several commits).
Several bugs were solved, and the feature feels pretty solid in testing on the button block. We might want to consider what to do with the navigation link block, whether to remove support initially since there's not much functionality on that block. The focus-visible state was also an open question.
I'm personally not sure what the situation is with backporting lib/block-supports/states.php. Those files aren't in lib/compat folder and they're not block php (which is automatically copied). There's no mention of this folder in the README (https://github.com/WordPress/gutenberg/blob/trunk/lib/README.md).
Block supports updates are usually manually copied across. I can open a trac ticket for this as i can't find any relevant open one. |
…r exported" This reverts commit 9f4e1fe.
|
I reverted a small change I added earlier (9f4e1fe). I remembered that slotfills can be accessed using the string name (e.g. I'll stop tinkering now 😄 |
tellthemachines
left a comment
There was a problem hiding this comment.
I think this is in a good place to merge and iterate on in follow-ups!
|
Thank you for taking over @talldan and @tellthemachines I am so excited for this! |

What?
Closes #38277
Follow up of #75627
Adds block-level pseudo-state style support — allows blocks to store per-state styles (e.g. :hover, :focus, :visited) in attributes.style[':hover'] and have them serialized into the block's rendered HTML.
Why?
Right now, hover/focus/active styles for blocks like Button can only be set in Global Styles. There's no way to give a single Button block its own hover color without changing every button on the site. This adds that ability.
How?
Blocks can opt in by declaring
"states": [":hover", ":focus", ":active"]in theirblock.jsonsupports. The Button block is the first to use this. This new API adds support for a UI to a feature we already had access to through theme.json, hence why I chose not to put it under an experimental flag.In the editor:
On the frontend (PHP):
.wp-states-IDclass for this on the selector defined in block.jsonNot in this PR:
useStylein Global Styles to accept a state param — that's a follow-up, on top of the work done in Implement state UI for pseudo selectors on Global styles #75627.Testing Instructions
Screenshots or screencast
Use of AI Tools
This PR was authored with Claude Code (Claude Opus 4.6).
(OpenCode / Codex for @talldan's commits)