Support focus-visible

[LarsDenBakker]

Chrome 86 will support focus visible:

• https://www.chromestatus.com/features/schedule
• https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible

It would be great to support this in the lion components as a progressive enhancement for browsers that support it.

[MathieuPuech]

I suppose something like @vaadin/focus-visible-mixin could be done?

[LarsDenBakker]

Interesting, I didn't know that existed. However I was thinking of just doing the CSS and have it be a progressive enhancement on browsers that support it.

[tlouisse]

Nice spec 👍
I think this comes pretty close to [focused] we currently have.
We use that attribute to style Lion FormControls (lion-input/lion-textarea/lion-select/lion-combobox etc etc.) when
a child (usually a native input node) gets focus.
See: https://github.com/ing-bank/lion/blob/master/packages/form-core/src/FocusMixin.js#L14
It works for all browsers, although only for FormControls at the moment.

@LarsDenBakker Wrt the progressive enhancement part, I think Subclassers could use this in their extension layer styles already, right?
Or do we need to change something in Lion for this?

[ffoodd]

If [focused] depends on children, it's closer to CSS :focus-within pseudo-class. :focus-visible depends on heuristic to determine if focus visibility is mandatory or not (mainly if it's triggered by keyboard).

The WICG has a very lightweight polyfill and the repos is also great at explaining the rationale behind this (also see the discussions).

The Paciello Group also has a write-up on how to use it defensively as a progressive enhancement, which is closer to the initial demand I think (CSS only feature).

[tlouisse]

@ffoodd you're right, I confused focus-visible and focus-within back then 🙂
Our [focused] attribute actually equals :focus-within indeed.

In FormControls there also might be a need for [focused-visible-within], see: #1206
I think we can achieve this by checking _inputNode.matches(':focus-visible') on focusin and as a backup we can add a MutationObserver to the class attr that checks the polyfill classes.

In all other cases, Subclassers can use the polyfill in their code.

Makes sense? All suggestions are welcome

[tlouisse]

It has been solved here: #1357

I will now shamelessly mark this as the right answer, but let me know when not all has been addressed :)