Could we just have a rule of whatever color, the hover should be a little darker?

I think the hover color should be a little darker than base color.

@monika-12 yes I agree and let's get this worked on now we have design feedback.

.wp-block-button__link:hover{ background:#3A3A3A !important; }
This is what I've added to custom theme CSS. Affects all buttons in that class. For now it works fine for me. The !important is important for override purposes, because for some strange reason somewhere else the background has been set already at :hover.

@karmatosed do you know if this has been deployed? I cannot find any docs about hover for buttons in Gutenberg.
thanks!

Hey

I am rechecking this issue.
Using Twenty Twenty One.
WordPress 5.6.
Gutenberg plugin version 9.8

As can be seen hover has not yet been added. Kjell linked to this issue (right above)
#27075

Is there any chance to have an option to add customized color in button hover color! For example, I want to add different hover colors rather than the light, darker version of the primary button color.
Sorry, please don't mind; other page builders have those features in default. Or you can check other third-party addons like stackable: https://wpstackable.com/button-block/

ultimate blocks: https://ultimateblocks.com/improved-button-block/

I really appreciate any help you can provide.

Thank you for adding your comment @Gtarafdar
I have shared the issue with @aaronrobertshaw . Aaron has added the issue to the list of things he is working on.

Ahh. Thanks a lot. I was waiting for a long. Because only for that feature I have to use another addon. Any ETA @paaljoachim, my brother.

Thanks for the ping @paaljoachim. I am currently working on adding block support for custom colors along with UI refinements around that. This will be a great use case to trial that new functionality.

That sounds great, @aaronrobertshaw !

Hi @Gtarafdar I will assume that Aaron will post here when he has some more information to share. ETA soon..:)

Yes, that's the plan 🙂.

There are still a few hurdles to resolve before we can offer a generalised approach to supporting custom colors. The idea though is that once this feature is available it could be used for:

• hover colors for a button,
• header/footer/striped colors for tables,
• different color/background combinations for nested blocks such as a nav menu,
• and many more.

With the addition of a potentially large number of controls to the sidebar, we need an improved method of displaying them. A PR adding a progressive disclosure panel supporting that goal can be found here: #32392.

When I have a working proof of concept up for custom colors I'll comment again here adding a link to it so its progress can be more easily followed.

@aaronrobertshaw: What's the status of this one? Is there anything minimal we can do in time for WP 5.9?

Thanks for the ping @noisysocks.

Progress has stalled a bit on these efforts. The PR I was working on was to be able to select secondary colors for the table block #33157. The hope was the same or similar approach could then be extended to other blocks, such as the button block here and its hover color.

The discussion on the PR lead to the creation of #33255. In a nutshell, we still need some changes to underlying APIs to be able to offer custom secondary colors.

The new ToolsPanel providing progressive disclosure of controls has only recently landed. With it now comes the ability for blocks to inject controls within existing block support panels such as the color panel. This opens up some options for us to use ad hoc solutions for some blocks until a generic option can be worked through. Regarding the color panel for block supports specifically, there is an open PR switching it to use the ToolsPanel. We'd need that to land as well before we can add too many more color controls.

Ultimately, I do not believe there is anything we can add on this front in time for 5.9.

Thanks @aaronrobertshaw! Happy to cut this from WP 5.9. My only concern is that Twenty Twenty-one might need it. What do you think @kjellr?

@jffng and I chatted about this yesterday, and we haven't found see a reasonable way of adding hover styles into the buttons manually on the theme side either. We can do it, but it takes a lot of extra CSS, and is generally prone to breaking.

At this point (if we don't think we can build hovers into Gutenberg), I'm leaning towards not building any button hover states into Twenty Twenty-Two for the time being. That way the buttons remain purely powered by Gutenberg, and we can just add hovers once they're supported by Gutenberg. It's not ideal, but it's also not going to break.

I'm a little unclear if hovers are required for a11y though, so I wonder if we can get some additional accessibility feedback? I'll drop a note in the #accessibility channel for feedback.

We received a response in Slack:

hover isn't required, but it can be helpful for some people with low vision to confirm their cursor is over the active element (i.e. can they click)... also worth noting that focus is required (e.g. someone using keyboard needs to know where focus is) - "2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)"

That makes a lot of sense. It sounds like button hovers are not technically required, but they are certainly helpful to many users. I'm torn between a couple recommendations at the moment:

1. Keep this in the Must-Haves so that its front-of-mind, but know that we can technically drop it last minute if we don't have a solution.

2. Remove it from Must-Haves here, but continue to pursue options for the theme to work around it to provide hovers. If we were able to make this work though it would require a potentially complicated CSS solution, which feels unfortunate (As of today, the theme uses no CSS at all, and I'm hesitant to break that!)

In any case, I don't think there's harm in letting it simmer over the weekend. Let's aim to re-evaluate next week.

As @kjellr mentioned, there is a fundamental issue to deal with. The current inline style mechanism cannot work for :hover, other pseudo classes, and also not for media queries.

The only possible way to make those work is through another mechanism. By having a CSS class with a separate declaration saved somewhere and then apply the class name to the block. So editing the styles in the sidebar would not update the block, rather the content of this class.

Perhaps that class is saved in the same post. Or in a custom post type like template parts. It has to go somewhere.

Which leaves the question: would it be desirable to add a second mechanism of managing block level styles on top of the current inline styles mechanism to complement all cases it doesn't cover?

I see no immediate drawbacks in using a class based mechanism for everything, if it needs to be there anyway. Except of course the significant amount of changes required to implement it and convert existing inline styles based code.

To me it seems worth the effort, to avoid being stuck with 2 very different ways of doing the same thing and all resulting complexity. On top of hover styles and a consistent API, there's more benefits:

• Media queries would also work allowing for responsive styles
• Potential for user created style re-use cross site

With only 2 days remaining I think we have no choice but to punt this one. I will defer to @kjellr on whether or not Twenty Twenty-two should employ a workaround for this issue or do nothing.

Ok, @jffng and I will make a call on that in WordPress/twentytwentytwo#99. Thanks!