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.

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

[scruffian]

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.

[jasmussen]

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.

[getdave]

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

I want to emphasis this as it's important.

---

@paaljoachim Thank you for the exploration!

[jameskoster]

One thing I'm curious about is how to represent the cascade as you manage different states.

If we just duplicate the default state then it becomes quite tricky for the user to understand which controls / values are inherited, and which are specific to the state they're editing.

For example, in the mockup below it takes a lot of scanning to work out the differences, and this is with both panels visible at the same time. Obviously it'll be much more tedious when you have to click back and forth.

Having per-panel state management helps with this, but convolutes the Inspector quite a bit when more than one panel entertains different states.

[paaljoachim]

I just want to add in here that there is a parallell discussion going on here:
Add Button Hover Color options on Button Block
#4543 (comment)

[shaunandrews]

I've been looking at an interface for interaction states. I think it's important that we design an interface that allows for multiple states, like both hover and active states. I also think it's important we design an interface that supports not only interaction states, but also content (or data) states, like loading, error, or empty.

CleanShot.2023-04-08.at.13.42.56.mp4

[paaljoachim]

That looks really good Shaun @shaunandrews
I do wonder if Link States should be in it's own panel component.

[nathanrodrigues2111]

This has to be a must have option for blocks especially navigation block. As even if we add hover using code its not easy for users to manage / change it using editor which is a really downside. Please if this could be taken as a priority would be really great, Thanks 🙂

[getdave]

From what I recall, the foundation of this feature is available in Theme JSON. What's needed now is someone to continue to implement a UI to expose this for all blocks that need it.

I won't be working on this during the 6.5 cycle as I am unavoidably focused elsewhere.

[deryckoe]

@getdave is there documentation or clue on how to add a new tab (for hover) to the color picker? I tried to find it with no success. I may be able to help with that.

[masteradhoc]

@deryckoe would be great. I'll be happy to help with testing if you want 👍🏻

[onetrev]

Just a thought, but it seems as though this issue, in particular the UI concerns, could be managed by the States proposal?

[jasmussen]

States was indeed 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.

[jasmussen]

Based on the response to the latest rounds of suggestions, I've gone ahead and refreshed this issue and added the "Needs dev" label.