Add Highlight State to Button, Tab, and MenuItem Components

[lawrencewin]

Platforms Impacted

• iOS
• macOS
• win32 (Office)
• windows
• android

Description of changes

For specific UI scenarios, some callers want to be able to indicate whether an element is highlighted, independent of whether native focus is on the item or not. Take a combobox as an example. Users need to be able to see which combobox item is highlighted all while still maintaining native focus in the combobox text input so that they can type and adjust their query.

FURN controls do not have an officially supported ability to force the render of a "highlight ring". This PR changes this by adding a separate highlighted state to the Button, Tab, and MenuItem components. Users can render the ring by simply updating the highlighted prop, which will render a native-like focus ring around the components, independent of actual focus state.

(note - the primary button renders a simple border. trying to render the two tone border in a highlight state causes an immediate crash on win32, and it's unclear why)

Verification

Highlight rings around button variants

Highlight ring around menu item no. 3

Highlight ring around tabs no. 1 and no. 3

Pull request checklist

This PR has considered (when applicable):

• Automated Tests
• Documentation and examples
• Keyboard Accessibility
• Voiceover
• Internationalization and Right-to-left Layouts

[Saadnajmi]

FWIW, I think Apple calls this "selected"

https://developer.apple.com/design/human-interface-guidelines/focus-and-selection

[PPatBoyd]

FWIW, I think Apple calls this "selected"

https://developer.apple.com/design/human-interface-guidelines/focus-and-selection

while highlight and selection can be the same depending on the scenario, they're referenced separately in your link as well as in AppKit and UIKit props/documentation e.g.
https://developer.apple.com/documentation/uikit/changing-the-appearance-of-selected-and-highlighted-cells
https://developer.apple.com/documentation/appkit/nsbutton/highlight(_:)

my high-level shorthand for distinguishing them is highlight is pre-commit and visually transient, and selection is post-commit visually stateful -- and my goto example for distinguishing highlight from selection from focus would be a controlled list of checkboxes :D

[PPatBoyd]

[discussion] specifically intrigued here at how you're feeling about the separation of state, styles, and props 🙂 and how we want to manage the separation long-term.

If I'm connecting my dots correctly -- and let me know if I'm not! -- the high-level scenarios we're currently wanting highlighted state are "controlled" state scenarios, particularly controlled lists for Win32 ControllerFor or plausibly MacOS general List purposes (where focus is on the entire List component, not the ListItem).

Do we want to separate highlight and have it be line-item added as a prop for components that want to offer controlled and uncontrolled styling patterns (e.g. button), where we'll have to carefully mind precedence and how multiple event sources (e.g. keyboard and mouse) interact?

Is there potentially value in more directly tying the component's available states to be available as a controlled set (prop) that has specific precedence/interaction with the uncontrolled behaviors -- potentially useful when there's no visual distinction between say, highlight and hover?

[PPatBoyd]

@JasonVMo in case you have any thoughts or opinions here or want to follow-up w/ offline group chat