Consistency of hover/focus/selected indicators

[jvine]

Definitions

Mouse hover indicates "this is an active thing you can click". Keyboard focus sometimes indicates "this is an active thing you can click"; sometimes actually triggers an action. We need to treat these separately.

Hover

• mouse is hovering over a control, or keyboard focus is on the control but no action has been triggered. e.g. icon buttons, menu options, index panel lists
• expressed as an altered background ("light")

Focus/Select

• mouse click or keyboard focus triggers a change in the canvas or panels. e.g. thumbnail nav, gallery view
• expressed as a different altered background ("dark"), or a coloured border, depending on context

Active/Pinned

• item is marked as selected to provide information/context, independently of mouse/keyboard activity. It remains in this state until something else is selected.
• expressed as a different altered background ("dark"), or a coloured border (sometimes combined with coloured icon/text)
• does not move when "hover" changes

In the light theme these visual states are currently rendered as:

• Light background: rgba(0,0,0,0.08)
• Dark background: rgba(0,0,0,0.14)
• Border: theme secondary colour #1967d2

Gallery view

Hover

• remove the current border and use the hover (light) background colour
  Keyboard & click behaviour are correct.

Additional theme change:

• set background for gallery view to white (light theme)

Active/pinned
Current behaviour is correct.

Thumbnail nav

Because the layout is so pixel-fussy, we propose using the outline property to provide both the hover and focus/selected states.

On the <div role="button">

• set a default of outline:0
• remove the current selected border
• for hover add

    outline: 9px solid rgba(0, 0, 0, 0.08);
    outline-offset: -2px;

• for active add

    outline: 2px solid #1967d2;
    outline-offset: 3px;

Additional theme change:

• set background for thumbnail nav to white (light theme)

Load window

Currently has no hover/focus indication.

Hover

• add the hover background to the div that contains the button (i.e. not the button itself, which looks weird).

** Active => #2495 **

Index lists

Thumbnail list, Compact list
Current behaviour is correct.

ToC
Basically:

• hover & keyboard focus get light background
• active item gets dark background
• parent items of the active item get the "pinned" left border

Additional style changes required, will be ticketed separately.

Annotations

Current mouse behaviour is correct.

No keyboard behaviour yet:

• follow the same pattern as index lists. Keyboard focus sets the hover background; activation sets the dark background. Add keyboard tab navigation to the annotation companion window #2564

Menus

Jump to window menu

Currently the first item in the menu has a dark background, which remains static even when the keyboard focus moves. This is the behaviour of an active/pinned item, implying that it might be associated with the currently-focused window, but it's not.

• Make the Jump to window menu behave like other menus: first item has the light hover background; that background should move when the keyboard focus moves. (Yes, this continues an ambiguous situation for mouse hover, true in all our menus.)

Window options menu (View as, Thumbnails)

Currently the active item uses only colour to differentiate itself, which is insufficient.

• add a 2px bottom border to the span that contains the text Add a 2px bottom border to selected WindowTopMenu options. #2569

Dropdown menus

Index selection
Current behaviour is correct.

Simple dialogs

Change theme
Active theme has dark background; keyboard focus moves that background. This should follow the pattern of the dropdown menus.

• Active theme should remained highlighted, while keyboard focus gets the hover background.

Images: keyboard (incorrect); mouse (correct)

Same applies to Workspace type dialog. This becomes more important when there are more than 2 options.

General cleanup

Mouse & keyboard states that are noticeably different for the same effective state

FAB
Currently, hover darkens the button; focus lightens it. This means a noticeably different experience for mouse vs. keyboard users. (Images: default, hover, focus)

• Make the FAB focus state match its hover state.

Sidebar tab icons
These seem to have an override hover style (#2205?) that fills the square of the tab. But the keyboard focus is the standard dark grey circle. Again, noticeably different experience for mouse vs. keyboard users. (Image: About = active; Rights = mouse hover; Index = keyboard focus)

• Can they be made to match? Hover & focus either both circles or both filled?

Collapse/expand panel icon

Forcing the background to be white on hover means... there's no mouse hover indicator. Keyboard focus gets the round icon-button background. Which pulses.

• the button needs a surrounding <div> with a white background, so the button itself can have standard hover behaviour.

Default outline

Sometimes the browser's default focus outline is showing through. We don't want to eliminate it globally, but to suppress it when it's inappropriate.

Presentation items in menus

• li[role=presentation]:focus {outline: 0;}

**Images in thumbnail navs

• see section above

Kill the pulse

ripplePulsate still happens when icon buttons get keyboard focus. Tab to any icon button to see the effect: FAB, app bar, window top bar, sidebar tab, canvas nav, panel headers, panel section collapse...

• kill it.

[mejackreed]

So in discussions with @jvine and @ggeisler and experimentation, I think we may need to depart from this in some ways. I'll try to outline the rationale here so this work can move forward.

Kill the pulse

Doing this disables keyboard focus indicators on any MuiButtonBase derived component. This causes problems elsewhere since now we need to readd focus indicators everywhere. Trying to do this globally runs into problems with a light/dark theme compatibility issue.

In our discussions, an acceptable alternative is to update Fab to have consistent colors for hover, and focus states.

[jkeck]

I'm going to grab just the annotations piece right now.

[jkeck]