Standardized way to modify interactive states (:hover, :focus .etc) for blocks

@javierarce

What problem does this address?

Currently it's not possible to modify the visual styles when the block items are in a given state (hover, focus, etc).

States (#57719) was designed as a solution that could work for this use case, including the hidden complexity that isn't immediately obvious. Consider a navigation menu, you'd want to be able to change colors of menu items in their neutral, hover, focused states. But most likely, you'd also want to be able to change their border, background, perhaps font-weight or text-decoration in those states.

Secondly there is the need to combine properties into new states. Consider the same navigation menu, menu items can have current states. E.g. when you navigate to /about, the "About" menu item should be highlighted as the current menu item. This state cannot inherit the hover and focus states from default menu items, you might have a blue hover color which wouldn't work if you added a black background:

In other words, the state proposal suggests that "Hover" is one property that can make a state. "Current" and "Hover" properties together, make a new state.

The state design can solve both those complexities:

By having the selector relate to the block itself, it provides access to the whole inspector and all tools within, to customize a state.
By allowing you to combine properties to create a new state, the use case of allowing design of the hover state for the current menu item is handled.

Here are mockups that extrapolate on Saxon's work to test it for both a Button state, and a navigation "current menu item" state:

This could work as a starting point, and as the states concept gains features, it can be expanded upon.

Figma.

Issue updated May 7th.

Past version of this issue

Examples include:

hovered
focused
active

Update

We've iterated on this in #1786 and #41976.

A video overview is available.

After #41976, the next steps are:

Fix Global Styles: Elements: Link style rules are being applied to buttons #42055
support :hover on link elements within **blocks** in Global Styles UI (currently only top level is supported).
implement the "disclosure" pattern from @javierarce's designs from Add link element :hover interactivity control to global styles UI #41976 (comment).
add support for :focus and :active states in the Global Styles UI for link.
Add color swatches for the first two "states" in the Global Styles element overview item (see Add link element :hover interactivity control to global styles UI #41976 (comment))
Enable setting Navigation block link color from global styles. Requires Migrate Navigation block color controls to Block Supports #42092 to be resolved as Global Styles checks supports to decide whether to enable the panel.

What is your proposed solution?

Provide design tools that allow setting visual presentation for those states.

Likely these will be implemented as an editor-wide feature rather than something that's specific to the Nav block.

I will defer to @jasmussen and @javierarce for their thoughts on how this might happen.

Also pinging @jorgefilipecosta who may have some insight onto whether Global Styles intends to handle this in future.

Definitely a good challenge. I wonder if we shouldn't zoom out from the navigation block, and look at this issue in more generic terms across all buttons and links. That would put the effort in global styles and design tools territory. One of the interesting challenges to tackle there, is building some confidence on exactly how we should support pseudo states. Do we need them all, or could we start with just hover/focus?

Related: #27075

@jasmussen

I think controlling these states from global styles makes sense and I agree with what @jasmussen said. But we need to be very careful how this is going to happen. It does not make sense to control states for a paragraph but maybe for the button block, it does? How do we specify which blocks this makes sense? I guess a block.json support? I guess for the link element it also makes sense so for some elements we are going to have states.
We would need to have a design exploration on how we can expose this UI in an easy-to-use way covering both states for blocks and for elements like but not taking much space so the global styles UI is still clean.

@jorgefilipecosta

Thanks @jorgefilipecosta. I agree it needs to be carefully thought through. Block supports sounds like a good way to indicate whether a given block is suitable for interactive state design tools.

I wonder whether UX wise this could behave in a similar way to the how Devtools handles these states:

@jasmussen are there any designers working (or planning to work) on this that you know of?

block supports sounds like a good way to indicate whether a given block is suitable for interactive state design tools.

Just adding a +1 that this would be both a very cool feature, and it will also need to be thought through carefully, both in the UI design, and how we wish to store the styling state. Over in #38167 there is a project underway (the style engine) to explore how we might improve our saving/rendering of block styles (this come out of the discussion in #37495). There's an initial PR for how the style engine might work in #37978.

Aside from the UI, how might hover, focus, active states be represented in the style object, both at the block level and in global styles? Do we need the style object to support nested values, scoped by a list of states, or something like that? How do we ensure we reduce duplication of data so we're not storing too many sets of the same values across multiple states (e.g. if we want the hover, focus, and active states to all be the same colours).

If it's first explored as an individual block support, it'd be good to also get an idea of how it could be centralised in the style engine (and / or made easy to change after the fact).

I think it makes sense to add this control to the theme.json before we build a UI for it. That gives us a chance to focus on the data structure and functionality and get that right without needing to think about the UI.

are there any designers working (or planning to work) on this that you know of?

I responded partially in Slack then forgot to copy it here. Here's an expansion:

It’s always easier to start with less, and expand when the need arises. There are a ton of pseudo selectors, and not all will be useful. Some can possibly be combined, such as hover and active into one.
It needs some good design explorations that consider these states in a global styles context, so the interface can be the same for both buttons and navigation items, for example.
Consider that each state isn’t just a single property change. A focus state is usually underlined, but it could also be a border with a radius, bold text, or a combination.

It's likely necessary to start with a combination of visuals and pseudo code to figure out a structure that works, and is able to grow if we find the need for a bespoke :active state after all.

Still wishing this was a thing. It feels like a major void in the fundamentals of building a website.

Apologies for piling on, but I do really feel this is a huge need, and one that users would expect to be something that is already there.

Yeah, sorry, I'm piling on as well for the same reason. If WordPress does not offer this, it supports inaccessible websites. We can't give users a no-code tool with which they can build out an entire website with template parts and the whole shebang, making them independent of the classic way of themes, and then expect them to know that they currently have to code focus state in manually.

I made my own standard with the hopes that whatever y'all come up with lands close to this. basically it's just css vars, In the editor I create a style object which is a lot like what blocks already have. these values are from block supports that skip serialization, or custom controls defined in the blockedit. this is clunky but it seems to work logically, and when it breaks the style is just not applied.

{
    "myStyleObject": {
        ":hover": {
            "color": {
                "background": "#fff",
                "text": "#000"
            },
            "typography":{
                "textDecoration" : "underline"
            }
        },
        "color": {
            "background": "#000",
            "text": "#fff"
        },
        "typography": {
            "textDecoration" : "none"
        }
    }
}

then, when rendering the block, those values are added to styles like:

<div class="wp-my-block" styles="
--color-text:#fff;
--color-background:#000;
--typography-text-decoration:none;
--hover-color-text:#000;
--hover-color-background:#fff;
--hover-typography-text-decoration:underline;
"
/>

then, in CSS i hook it up to where ever I like, which is especially handy because the selectors api doesn't target all the possible supports. below is a default, but you could target anything really

.wp-my-block {
    color: var(--color-text);
    background-color: var(--color-background);
    text-decoration: var(--typography-text-decoration);
}

.wp-my-block:hover {
   color: var(--hover-color-text);
   background-color: var(--hover-color-background);
   text-decoration: var(--hover-typography-text-decoration);
}

with an added bonus, that i can add this to additional css in the global styles for a block and it's applied to all blocks that don't have the block level settings

--color-text:#fff;
--color-background:#000;
--typography-text-decoration:none;
--hover-color-text:#000;
--hover-color-background:#fff;
--hover-typography-text-decoration:underline;

there are no forks given if a block supports text decoration,

Someone already mentioned the problem, but for anyone triaging, this issue formally needs the [Focus] a11y label added. The navigation block comes out of the box disabling default hover states (text underline) and no focus styling, meaning it comes out of the box inaccessible.

The navigation block comes out of the box disabling default hover states (text underline) and no focus styling, meaning it comes out of the box inaccessible.

Looking at a fix for this here: #72643

🔥

Outstanding work everyone.

Navigation Menu

Repository navigation

Standardized way to modify interactive states (:hover, :focus .etc) for blocks #38277

What problem does this address?

Update

What is your proposed solution?

102 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Standardized way to modify interactive states (:hover, :focus .etc) for blocks #38277

Description

What problem does this address?

Update

What is your proposed solution?

Activity

getdave commented on Jan 27, 2022

jasmussen commented on Jan 28, 2022

MaggieCabrera commented on Jan 31, 2022

jorgefilipecosta commented on Feb 1, 2022

getdave commented on Feb 2, 2022

andrewserong commented on Feb 3, 2022

scruffian commented on Feb 3, 2022

jasmussen commented on Feb 4, 2022

102 remaining items

hanneslsm commented on Feb 21, 2025

JiveDig commented on Apr 11, 2025

le-sgs commented on Jul 9, 2025

Bovelett commented on Aug 1, 2025

hadamlenz commented on Sep 12, 2025

ethanclevenger91 commented on Oct 20, 2025

scruffian commented on Oct 23, 2025

jasmussen commented on May 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions