- From: Brian Kardell via GitHub <sysbot+gh@w3.org>
- Date: Fri, 29 Jan 2021 21:22:42 +0000
- To: public-css-archive@w3.org
So, it seems there is some confusion here and I think that some of this actually comes from how we have written things as much as anything else. Here are the _current_ heuristic rules from the spec. They are bullets in the spec, but I am using numbers to make it a little easier to compare, but I guess I also think they are ordered points... 1. If a user has expressed a preference (such as via a system preference or a browser setting) to always see a visible focus indicator, the user agent should honor this by having `:focus-visible` always match on the active element, regardless of any other factors. (Another option may be for the user agent to show its own focus indicator regardless of author styles.) 2. Any element which supports keyboard input (such as an input element, or any other element which may trigger a virtual keyboard to be shown on focus if a physical keyboard is not present) should always match `:focus-visible` when focused. 3. If the user interacts with the page via the keyboard, the currently focused element should match `:focus-visible` (i.e. keyboard usage may change whether this pseudo-class matches even if it doesn’t affect `:focus`). 4. If the user interacts with the page via a pointing device, such that the focus is moved to a new element which does not support user input, the newly focused element should not match `:focus-visible`. 5. If the active element matches `:focus-visible`, and a script causes focus to move elsewhere, the newly focused element should match `:focus-visible`. 6. Conversely, if the active element does not match `:focus-visible`, and a script causes focus to move elsewhere, the newly focused element should not match :focus-visible. ------------- I kind of think that we're getting trapped in some words/phrasing... I think this is the problematic part "If the active element matches :focus-visible, and a script causes focus to move elsewhere". I believe that what I am seeing is mostly that how it is being read isn't uniform: Emilio has interpreted this (I think) as "as focus is initiated, look to see if there is an active element". Thus, if a blur has happened, there isn't, so to him his treatment makes sense. However, maybe a better way to say this is ""we look at how they last interacted with the page". Thus, if you look at rego's examples, and consider Alice's followons about blur and her pens, you can see that she is trying to show that's not right. I kind of personally feel like our initial take on this which talked somehow about modality was important. I kind of still wonder if there should be some concept like that, as least in words (though, in practice even a prop might be good)... In any case, I have attempted to provide a _modified_ set of rules that @alice and I, I think, would agree too and I wonder if make the intents clearer? 1. If a user has expressed a preference (such as via a system preference or a browser setting) to always see a visible focus indicator, the user agent should honor this by having `:focus-visible` always match on the active element, regardless of any other factors. (Another option may be for the user agent to show its own focus indicator regardless of author styles.) 2. Any element which supports keyboard input (such as an input element, or any other element which may trigger a virtual keyboard to be shown on focus if a physical keyboard is not present) should always match `:focus-visible` when focused. 3. If the user interacts with the page via the keyboard, the currently focused element should match `:focus-visible` (i.e. keyboard usage may change whether this pseudo-class matches even if it doesn’t affect `:focus`). 4. If the user interacts with the page via a pointing device, such that the focus is moved to a new element which does not support user input, the newly focused element should not match `:focus-visible.` 5. If the user has not interacted with the page, and a script (or similar behavior via autofocus) causes focus to be set, the newly focused element should match `:focus-visible` 6. If the user's last interaction with the page would cause an element to match `:focus-visible`, and a script causes focus to move elsewhere, the newly focused element should match `:focus-visible`. 7. Conversely, if the user's last interaction with the page would cause an element to to not match `:focus-sible`, and a script causes focus to move elsewhere, the newly focused element should not match `:focus-visible`. -- GitHub Notification of comment by bkardell Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5885#issuecomment-770057301 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 29 January 2021 21:22:44 UTC