Consider a standardized way to modify hover/focus/active states for blocks

[kjellr]

Gutenberg should consider adding a way for users (and/or theme developers) to modify hover and active states. This would ideally be available in the UI on a per-block level, and also a part of global styles. This feature would be particularly useful for link styles and also for buttons.

Related to #4543

[karmatosed]

I would love to see more consistency in the way hover/focus/active states behave themselves, which to me leads to a more consistent way for them to be styled. I have been working on an example to refine the gallery block borders (#27312), which overlapped. Even a small change like that was a bit of a tangled thread to follow due to the nature of the block. Which makes me feel this is an opportunity to refine and standardize.

[MaggieCabrera]

I've been working on Seedlet's button hover states and I feel like the solution that I found shouldn't have to be replicated for every theme that is ever developed. Even if it's never surfaced to the user the ability to change the hover color/background should be handled by the editor to some capacity. In particular when the color is one that is selected by the user and not one provided by the theme.

For the particular case, I was considering that we could either play with the opacity of the background color (using rgba) or play with the lightness (using hsl). Could this be done directly within the editor? As it stands, a custom colored button doesn't have any hover state.

[carolinan]

Changing the color alone is not enough to indicate that the state of the link (button block) has changed,
unless the color contrast ratio between the two colors is significant. What the minimum contrast ratio is also depends on factors like the font size. https://developer.wordpress.org/coding-standards/wordpress-coding-standards/accessibility/#color-contrast

If there is a hover color option exposed to users, it may need to be a selection of suggested accessible colors, based on the current button color(s), and refreshed if the user changes the button color.

[Tropicalista]

I added recently an issue: #30068

I suppose that hover is not integrated yet because there's no way to add pseudo class on inline style. A different approach to add custom hover effect should be proposed.

[getdave]

I'm going to add this for discussion in the Core Editor chat. It's something we are going to need for the Navigation block.

[aurooba]

So I think one of the considerations is what changes with each state. A state change isn't just a change of color or text-decoration, in CSS speak. It could be multiple things.

I would suggest that for each state, all currently supported properties remain available, so if the block supports background color, margin, padding, and letter case, then you should be able to control each of those per state. This will likely need some CSS adjustments, but should be pretty achievable with CSS variables.

[joyously]

I would suggest that for each state, all currently supported properties remain available, so if the block supports background color, margin, padding, and letter case, then you should be able to control each of those per state.

I disagree because of what can happen when hover changes the size of an element. It has been seen before in the editor that just hovering creates a scrollbar or other size change, which then moves the element so it's no longer hovered, so it changes size again. This creates a flickering of the element that can cause seizures. Even a little movement is annoying.

I don't think the editor should support the hover, active, focus, visited except on links. If it's standardized, the correct order is maintained. Be aware that visited can only affect color, though. I'm in favor of leaving it to the theme, not the user.

[Luehrsen]

Just to chime in with a real world example, this is how we approach states in our client themes at the moment.

.has-primary-color {
	--current-color: var(--color-primary);
	--current-hover-color: var(--color-primary-hover);
	--current-contrast-color: var(--color-white);
	color: var(--color-primary);
}

.has-primary-background-color {
	--current-background-color: var(--color-primary);
	--current-hover-background-color: var(--color-primary-hover);
	--current-contrast-background-color: var(--color-white);
	background-color: var(--color-primary);

	&.has-background-dim {
		background-color: var(--color-primary);
	}
}

These variables are then picked up and combined in the elements that have state and are used accordingly.

[scruffian]

Right, but this should really be handled by Gutenberg rather than every theme having to maintain their own version of this code.

[joyously]

but this should really be handled by Gutenberg rather than every theme having to maintain their own version of this code.

What is a theme for, then?
I don't think the user should be involved, so there should be no UI for it, so the editor should not care what the theme does with those styles.

[aurooba]

I don't think the user should be involved, so there should be no UI for it, so the editor should not care what the theme does with those styles.

I disagree. The option for the user to be involved should be there, with the ability for theme authors to disable user customization of this feature if they wish.

That is how the Block Editor has operated since being merged into core, and long term, that is the best approach. Provide the most flexibility and add curation/locking/limiting options that theme authors can utilize (I want to emphasize that flexibility without the ability to curate/lock/limit is terrible, and features should be developed in tandem with their ability to be locked down). This is important because a very large part of the WordPress end user community are DIY-ers who often start with a theme and then customize on top of it. I'm not a DIYer, but even if I find this helpful when I'm working on personal projects and need to do modifications quickly.

[Luehrsen]

Right, but this should really be handled by Gutenberg rather than every theme having to maintain their own version of this code.

This implies that Gutenberg could handle every style a designer throws at a frontend developer. Considering Gutenberg competitors with a far superior scope (like Webflow, Squarespace, Wix), this is simply not the case. You will always be locked in by the capabilities of what the editor team deems worthy and would stifle innovation and creativity outside of what the team anticipated.

[paaljoachim]

@critterverse Channing shared a link to @javierarce post here which is interesting to share into this issue: http://work.javierarce.com/2021/09/14/interaction-of-color/

[getdave]

Thank you for the varied opinions expressed here. It's really great to see this discussion evolving.

For my part, I'd like to add that I don't see this as a binary choice.

My opinion is that handling some basic interaction styles (such as color) would be appropriate for the editor to handle. Indeed, many users will likely want to be able to have some control over these most basic of design choices.

That doesn't mean however, that Themes won't still be able to augment or override those settings via CSS to provide additional creativity. We could even have an option within theme.json to disable the ability to edit these interaction states.

What we don't want is anyone to be "locked in" or for any creativity to be stifled. I hope what I'm suggesting above addresses at least some of those concerns.

[oandregal]

Braindumping some thoughts regarding a particular detail we should address is how user choices affect states.

A theme may want to set the blue color for the rest state and the yellow one for hover. Is the user sets the rest color to a yellowish base, is it still good to have yellow for hover? A related though is that different states may require any CSS property to update, like for example padding or margin, as in this use case. In this sense, states are more like "block style variations" than they are "style properties".

One of the issues is that the theme lacks information about whether an user has styled anything. Or rather, there's no way for a theme to "maintain the design links" when the user edits something. I've shared a potential direction to explore.

[cbirdsong]

A related though is that different states may require any CSS property to update, like for example padding or margin, as in this use case. In this sense, states are more like "block style variations" than they are "style properties".

Updating properties that affect layout on hover/focus is generally considered a very bad idea. Would we really want to encourage that?

[getdave]

For anyone watching this Issue you might like to keep an eye on #38277 which is where design progress is being made on this problem.

[talldan]

I'm not sure if this is still in progress, but the PR was closed so I've removed the assignment and In Progress label.

For anyone watching this Issue you might like to keep an eye on #38277 which is where design progress is being made on this problem.

@getdave From a triage point of view, what do you think about rewording the title and description of #38277? It seems like the conversation is no longer about the nav block, and it has become a duplicate of this issue. Potentially this issue could be closed or become an overview while #38277 becomes the design exploration.

I also don't think we want separate issues for adding hover states to individual blocks because that would become unmanageable. I just closed #42829, but I think it's confusing for the reporter that I'm pointing them to an issue for the nav block.

[getdave]

I agree @talldan. Let's close this one in favour of #38277 which, for whatever reason, has become canonical.

I'm not sure if this is still in progress, but the PR was closed so I've removed the assignment and In Progress label.

It's still on my radar but I've switched focus to the Nav block for a while.