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](https://www.youtube.com/watch?v=XikXzLLojhk) is available. After #41976, the next steps are: - [x] Fix https://github.com/WordPress/gutenberg/issues/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 https://github.com/WordPress/gutenberg/pull/41976#issuecomment-1170067066. - [ ] 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 https://github.com/WordPress/gutenberg/pull/41976#issuecomment-1170078408) - [ ] Enable setting Navigation block link color from global styles. Requires https://github.com/WordPress/gutenberg/pull/42092 to be resolved as [Global Styles checks supports to decide whether to enable the panel](https://github.com/WordPress/gutenberg/blob/b5de5fc1af8acbd83495d045f7d86aa902c9ae2f/packages/edit-site/src/components/global-styles/hooks.js#L173). ## 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](https://github.com/WordPress/gutenberg/issues/27075) 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.

[masteradhoc]

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

[draganescu]

I've updated the description of the issue with the update from @getdave . Basically there are some steps to go after https://github.com/WordPress/gutenberg/pull/1786 and https://github.com/WordPress/gutenberg/pull/41976 -

[paaljoachim]

This comment with a mockup from @mtias seems very promising and uses a UI method used in general in Gutenberg.

https://github.com/WordPress/gutenberg/pull/41976#issuecomment-1170078408

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

[jarekmorawski]

I used the new state management UX in a new Tabs block I'm working on and received feedback about surfacing the states more prominently at the parent block level (Tabs > Tab). Should we consider it as a future improvement? What if we used a drawer-like UX for state management?

[jasmussen]

Nice. This panel has the same challenge as some of the older mockups, though, where for each state you actually want the full block inspector's suite of tools available for every state. So the question becomes, what do you see when you click any of these states? Or is the entire panel meant to be contextual to what you choose in that state panel?

The inspector-top state dropdown for selecting the active state comes with the benefit that it is implied to be global to the entire inspector. It also reduces the prominence, which is useful since in most cases you don't have to customize hover or focus states—those are simply inherited by the defaults that are shown if no state is selected.

[jarekmorawski]

So the question becomes, what do you see when you click any of these states? Or is the entire panel meant to be contextual to what you choose in that state panel?

Good question. I'm not sure that'll be the case for every block, but the Tabs and Accordion blocks I'm working on would likely only need style-related options in the state panels. For instance, does it make sense to change the layout (width, orientation, justification, etc) just for an unselected tab? Surfacing styles (color, typography, dimensions, border) would give them more prominence while keeping the IA relatively simple.

It also reduces the prominence, which is useful since in most cases you don't have to customize hover or focus states—those are simply inherited by the defaults that are shown if no state is selected.

That was my initial approach too, but the feedback I got was that the controls aren't prominent enough. It came from a few designers who are arguably a good representation of the target audience for this part of block customization. They mentioned they were looking for hover and focused states specifically, so tucking them away behind an ellipsis can be counterintuitive.

Conversely, the placement in the Styles tab like in the design I shared earlier isn't perfect. All other settings in the Style tab refer to the block, but this section is more about block variations. I think putting them in the block details area makes more sense, but I wonder if we'd tweak the UI to give them a bit more prominence.

That being said, I know we explored this extensively in the past and didn't come up with a better solution. Perhaps the feedback I got doesn't necessarily represent the majority? We can either continue exploring or wait and see how the UX works in real-life situations.

[paaljoachim]

@jarekmorawski I find it intriguing/interesting that perhaps using the variations area where the state can be listed would be an interesting approach as you show it just above here. Perhaps the variation area should be more used than what it currently is. Under the button title is also shows the current variation selected which makes it also highly visible for the users.

Whatever the approach may be, the result can be an experiment which can be added to the Gutenberg experimental screen so that we can test out a version and get a feel of the flow. Then based on testings modify the UX.

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