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!

[jasmussen]

Here's a new approach to pseudo states. Which is Style Book-first, or if need be, even Style Book only:

The idea is to extract all the different states of button, navigation items, etc, as separately displayed blocks in the style book. This would allow you to, using existing block inspectors, style each state as you please. Combined with work from #37752, it should be clear which styles are inherited in the states, vs. which you need to customize for that aspect.

Included in this mockup is also the navigation item current state (#42299).

As-is, I believe this would provide a relatively simple way for a theme developer to style the necessary states across the buttons and menu items that need it in a global sense. It would solve the main issue here, and given its potential simplicity both UI and implementation wise, it might be a good first step. Finally, it wouldn't preclude future explorations to surface additional controls in a local setting, should that still be necessary. Penny for your thoughts?

CC: @WordPress/gutenberg-design

[jarekmorawski]

I've been following the work on bringing states to the Style Book from afar and I think it's a great solution for blocks like buttons that need consistency across the site. How do you think it could expand to other blocks?

For instance, the Query Loop block has an empty state currently displayed in the canvas below the block's default content. The QL block can be inserted on any page and template and its contents are often specific to the context, so I'm not sure it belongs with the Style Book.

Do you think it should be editable similarly to buttons and links or does it deserve a different UI treatment?

[MaggieCabrera]

As-is, I believe this would provide a relatively simple way for a theme developer to style the necessary states across the buttons and menu items that need it in a global sense. It would solve the main issue here, and given its potential simplicity both UI and implementation wise, it might be a good first step. Finally, it wouldn't preclude future explorations to surface additional controls in a local setting, should that still be necessary. Penny for your thoughts?

Yes!!! This is important to bring into the hands of designers/theme builders and the Style book would be the perfect place for it. I love it.

[jasmussen]

For instance, the Query Loop block has an empty state currently displayed in the canvas below the block's default content. The QL block can be inserted on any page and template and its contents are often specific to the context, so I'm not sure it belongs with the Style Book.

There seems here to be overlap with the need for block states like subscription blocks that may need to show free vs. paid content, or even cart blocks that can be empty or full. The closest we have to that at the moment, is the Custom HTML block which allows a preview, which is admittedly not the best interaction. Style book may indeed be a place for it, but it may also be useful to be able to see in the canvas. Is there an in-between? Here's the Figma, by the way, in case you'd like to tinker!

Great feedback, all!

[fabiankaegy]

Maybe we could also tackle this problem (in stylebook) in a more flexible open way.

The BlockBook tool @youknowriad built a few years ago had the concept of "Stories". Kind of like Storybook also works: https://youknowriad.github.io/blockbook/block/core---cover/stories

Core could register stories for all the states we want to showcase. Whether they are pseudo states or actually different states a block can be in like the query example by @jarekmorawski above

[jasmussen]

Nice, yes. Does that need to be accounted for in this mockup, or could we start with Button and Navigation Item blocks and then subsequently follow up?

[jarekmorawski]

That's fine by me if we agree the other use cases should be covered by a different UI. I'm not convinced the Style Book is a good place to interact with contextual block states. The toolbar (or something in the Inspector) could be a good start, but it does raise questions: should it integrate with Style Book somehow? For instance, if Style Book becomes the primary interface for editing button states and we build a different UI for managing block states, should the Button block use it when I add to a post or page?

[getdave]

I appreciate the Style Book approach which might work well for Theme authors or very experienced users (caveats to this below).

However, I don't think it will work for less experienced folks who just want to change visual states on a specific Navigation block. For example, how often do you want to set a standardised :hover style for all your Navigation blocks? Usually you are defining it on a case-by-case basis (e.g. states for Primary Nav in header, different ones for your Footer Nav...etc).

For this reason I still believe that ultimately we will need an "inline" means of toggling between states in the block inspector.

[jasmussen]

Valid feedback and point, yet I feel exactly opposite to what you describe:

For example, how often do you want to set a standardised :hover style for all your Navigation blocks? Usually you are defining it on a case-by-case basis (e.g. states for Primary Nav in header, different ones for your Footer Nav...etc).

I would set the standized hover/active/current styles for all my navigation blocks, of which I'm most likely to have only one or two, on the theme design itself. I'd do that once, and then never revisit it in a local context.

That isn't do dismiss the need for inline controls, which is why it's good that the Style Book approach wouldn't preclude this. But through having a smaller UI footprint, hopefully it would get these tools into theme author hands sooner than the local approach. What do you think?

[fabiankaegy]

However, I don't think it will work for less experienced folks who just want to change visual states on a specific Navigation block. For example, how often do you want to set a standardised :hover style for all your Navigation blocks? Usually you are defining it on a case-by-case basis (e.g. states for Primary Nav in header, different ones for your Footer Nav...etc).

For this reason I still believe that ultimately we will need an "inline" means of toggling between states in the block inspector.

@getdave what I meant was using the concept of stories to be able to define what "variation" / "states" get exposed in the style book interface. Not that they would / should be used to edit the states :)

[getdave]

I appreciate the valid push back here 👍

....most likely to have only one or two, on the theme design itself.

You are probably right that some (not sure if it's most though...) Themes only have a single "Primary Navigation". What you envisage is suitable for this scenario.

However, many Themes have multiple Navigations. This includes the default TT4 Theme which has:

• Header Nav - horizontal orientation links.
• Footer Nav - vertical "stacked" links.

Now imagine the header template part area uses a different color to the footer template part. If I use Style Book to set the states for all my Navigations then it won't work.

This is why I'm glad we aren't precluding the requirement for inline controls. This Style Book approach might work as a stop gap, but I can't see it working for anything other than the most basic of Themes.

[paaljoachim]

It sounds like the discussion is about adding an easier approach to styling navigation through a Global area and then later on adding it also locally so one can adjust it for any Nav directly overriding the Global approach.

[simonwammerfors]

I appreciate the Style Book approach which might work well for Theme authors or very experienced users (caveats to this below).

I understand that creating a UI for managing states is a challenge, and that Joens suggestion certainly has some benefits. As a theme author I doubt I would ever find these controls at all if they were tucked away in the style book though. I already struggle sometimes to find a certain control I know exist somewhere. The other day I wanted to try this image lightbox thing and had to resort to googling. Realised that I had to go to global styles to find it. To limit certain controls to the style book would mean that there now are three places where controls for one single block may reside: the ordinary block controls, global styles and global styles with style book activated.

[mateuswetah]

It seems that most of the discussion here is moving towards two solutions:

1. A wider concept of states (stories, if you like) that is emerging to a clear and interesting direction in the style book mockups;
2. The "inline" concept of states or pseudo-states (hover, focus, active, etc), which is clearly more complicated to implement a UI for;

While I understand the challenge that 2 brings I would reinforce the importance of working with it. The navigation example that @getdave gave has had some arguments but for me there are even more situations... take the Button block:

Your theme developer might have planned it to be red or even have some nice variation that is green. But as a daily user you hit that situation where you really want it to be blue. If we don't offer some UI to do it, the user will never be able to create a coherent button that is blue by default but darker (or lighter) blue when hovered. I know one might argue that user should stick to the theme options and that should be a theme-designer choice... but if so we shouldn't even offer a background color change option at first, right?

Similar arguments can be made with the solid vs. outlined states... in the end I believe offering a UI for this is hugely important for Gutenberg to work well, even for classic themes. Once in a while I have to install a plugin just for a simple link or button because the lack of state control would bring me accessibility issues.

[jasmussen]

Classic theme support is a good argument for starting with the style book approach, since the style book is likely somewhat easy to make available to classic themes.

[mateuswetah]

Classic theme support is a good argument for starting with the style book approach, since the style book is likely somewhat easy to make available to classic themes.

Is it? Wait I didn't knew that it actually makes me really excited for that possibility 🤯

[jasmussen]

Surfacing the Style Book to classic themes is a way to let you style every block your site can use, without necessarily having any block templates. So it's an idea that seems interesting.

[t-hamano]

Classic theme support is a good argument for starting with the style book approach, since the style book is likely somewhat easy to make available to classic themes.

This probably shouldn't be difficult. See this comment.

In that comment, an experiment is trying to expose the Style Book and the global styles to the classic theme, but it should also be able to expose just the Style Book.

[jasmussen]

In that comment, an experiment is trying to expose the Style Book and the global styles to the classic theme, but it should also be able to expose just the Style Book.

Global styles would need something visual, so you can preview the styles you are applying. I'd definitely surface the style book along with global styles, in classic themes. Exposing the template editor would be less useful if block templates are not leveraged.

[jasmussen]

Connecting some dots to #66376 which would make it substantially simpler to find these exploded state views.