- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Jan 2021 11:18:20 +0000
- To: public-css-archive@w3.org
> > ... I think the Firefox behavior is the right one, because otherwise you don't show outlines for random focus moves that the user has no way of knowing about. > > There's not much practical difference between > > ```js > newFocusTarget.focus(); > ``` > > and > > ``` > document.activeElement.blur(); > newFocusTarget.focus(); > ``` > > Why should they result in different behaviour? Well, because the way you're "transferring" the knowledge of whether focus came from a pointing device or keyboard or what not in the rules in the spec is via whether the previously focused element matched `:focus-visible`. It's an heuristic, there's nothing saying that the page can't move the focus 10s later randomly after you click a button, and the focus won't be visible then. But the heuristic is useful because that is unlikely to happen. > My answer is that if the user is not about to use the keyboard, they don't need to know, and the remainder of the rules (including my proposed language from [#5885 (comment)](https://github.com/w3c/csswg-drafts/issues/5885#issuecomment-765008329)) ensure that in the majority of cases where they would be likely to be interested in what element is focused, the focus is shown. Well, sure, but you can't guess intent from a `focus()` call. For example, I find the firefox behavior quite useful when I'm going back to a tab (Firefox will programmatically restore the focus to where it was, so I know where the next tab key press will get me). -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5885#issuecomment-767476954 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 26 January 2021 11:18:22 UTC