GU Yiling

Or can we ship a separate [ponyfill](https://github.com/sindresorhus/ponyfill) version? Usage in Uppy can be: ```js import focusVisible from 'focus-visible-ponyfill' focusVisible({ scope: '.uppy', // a selector, defaults to `:root` className: 'uppy-focus-visible' //...

I think `:has(:focus)`/`:has(:focus-visible)` are better than `:focus-within`/`:focus-visible-within`. Maybe `:has` is too big a thing to proceed?

A good news: folks from Igalia is working on implementing `:has` for Chromium. https://bugs.chromium.org/p/chromium/issues/detail?id=669058#c17

I believe it's intentional and not framework-related. Focusing an input indicates that the user should switch their input modality to keyboard. https://github.com/WICG/focus-visible/blob/ea5722da398ae6cdc3bb23251486e07985d5e2e4/src/focus-visible.js#L59-L69

I’m afraid this requires double your style declarations for `.focus-visible` to make it work with or without the “polyfill” (technically this project isn’t a real polyfill).

It seems that programmatically focused elements are not receiving `.focus-visible` by any means currently. In fact I think such elements should **always** match `:focus-visible` because even if they are focused...

> i'm using spacebar to press the other button because mouse clicking the first button calls focus() on it @robdodson, yes that's indeed the problem I've been suffering from. Programmatically...

I prefer `:focus-visible` over the current behavior of Firefox/Safari (which seems to be a hack to somehow mimic the visual effect of Chrome's behavior) because the later one introduced side...

> bah! I realized the PR only solves the issue if a keyboard was used. Yep. That's why I proposed to only exclude focuses following a pointer event (`mousedown`, `touchstart`,...

> exclude focuses following a pointer event And we have to check if the focused element is the same as the one received the pointer event earlier. If not, it...