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

[getdave]

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.

[getdave]

Also cc'ing @annezazu who suggested this idea.

[jasmussen]

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?

[MaggieCabrera]

Related: #27075

[jorgefilipecosta]

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.

[getdave]

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?

[andrewserong]

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).