Hover on selected item: #e9effa	Accent90: #eaf3ff

Just wanted to point out the amount of difference there would be between the hover state of a normal menu item and a selected menu item. No opinion here, just an FYI.

@Prtksxna Thanks for the comparison. Yes, there might be another change considered as well.

Related to T110051: Reconsider Flow's use of .mw-ui-hovericon (dropdown menu items that gain progressive/constructive/destructive styling on hover).

In T166560#3319332, @Volker_E wrote:

Reassigning this to @Pginer-WMF as it needs design support on clearer outlining current shortcomings and proposed improvements.

I created examples for the use of accent90 light blue used on hover:

• On menus
  • We can use this variant if it is important to distinguish the active+hover state, although it introduces a new color variant for it.
• On lists of pages

I think the color combinations can work well, while still distinguishing the relevant states. Thoughts?

@Pginer-WMF Thanks for creating these demos . Summarizing the change you're suggesting for the menu.

In T166560#3830448, @Pginer-WMF wrote:

I think the color combinations can work well, while still distinguishing the relevant states. Thoughts?

I agree, these work well. Also, changing the hover background from gray to blue, as you have done, makes the selected + hover state more predictable.

I think too, that the :hover amendment to Accent90 works well, but I need to add a few details to currently in-production way:
The :active way is different (active is also known as mousedown, while the active described above is a selected state) already, it takes selected foreground color and a bit darker background rgba( 41, 98, 204, 0.1 ).
This is important for UX as action indicator and we should make use of the option.
Compare current behaviour of for example Outlined BookletLayout's menu.

To sum up:

• Giving selected+hover a special case doesn't seem important to me (as you can't chose to unselect those items nor usefully interact with them in current technical prospect), but there is an important differentiation in this case between
• :hover
• :active
• selected (selected+hover equals selected)
• selected:active equals :active OR doesn't change at all, probably looses cursor: pointer, although this has been opposed as too jarring in another similar use case on OOUI earlier

In T166560#3833393, @Volker_E wrote:

• Giving selected+hover a special case doesn't seem important to me (as you can't chose to unselect those items nor usefully interact with them in current technical prospect), but there is an important differentiation in this case between

I was considering "selected+hover" distinction not to be very relevant initially, but there is a good point Prateek brought up: keyboard use. When moving with keyboard through a list, we are using the hover state as the way to indicate where the focus is on menus. If you move through 3 selected items next to each other in a menu, you won't notice which is the current selected one if all the selected elements are displayed the same (making no distinction of which is the one with the focus).

One alternative to provide some support to that case without introducing a new color could be to use accent30 dark blue for the text on selected elements when hovered/focused to distinguish them from the non hovered/focused. The distinction is subtle, but at least provides some cues of where you are, if we consider this usecase important. I created an example and captured a gif simulating the keyboard interaction:

Getting more complex than I was hoping here, you're right, there is the special case of keyboard navigation.
Pitifully we're not consistent in it.
If you look into the Toolbars demo, menus in the toolbar giving only keyboard navigation feedback on :focus per tab while very late and weird (first scrolls the page) also work with arrow keys.
That's an experience contrast to the navigational dropdown in the left upper corner. (Should be filed in a related task)

Not sure though, if the slight color change treatment for this case is best-possible solution. I'd rather stay with our focus outlines whereever we can over such small color differences.

In T166560#3833518, @Volker_E wrote:

Not sure though, if the slight color change treatment for this case is best-possible solution. I'd rather stay with our focus outlines whereever we can over such small color differences.

It's not the best-possible solution in general. I was presenting it as a possible solution in the intersection of "avoid no signal at all" and "use only the existing palette without adding new colors". For the specific keyboard interaction, there is an expectation of the next item to react and even a subtle change may help users to get oriented.

Note that we are not talking about keyboard navigation in general, but the specific case of navigating through a sequence of selected elements. So we need to consider in that context which level of support to provide. I'm ok to find ways to support this edge case better, but I think we need to be careful not to do so at the expense of making the regular cases worse.

@Pginer-WMF I've forked the CodePen and:

• added :active state as currently defined
• added Accent50 as selected color to strengthen difference between :hover and selected items (is also currently the case)
• refined transition from current OOUI state
• made use of <a> elements as they support :active out of the box similar to our OOUI menu items

With that I think that the selected:hover state is a bit out of touch to the rest. Thoughts?