Re: [csswg-drafts] [selectors] :focus-visible matches on initial programmatic focus (#5885)

The CSS Working Group just discussed `[selectors] :focus-visible matches on initial programmatic focus`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  [selectors] :focus-visible matches on initial programmatic focus<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5885<br>
&lt;Rossen_> q<br>
&lt;dael> rego: This is about if focus-visible should match after programmatic focus. Current heuristics, though not normative, talk about if active element matches then next element will match. Spec didn't mention anything about if there's no active element<br>
&lt;dael> rego: Proposal is to change a bit so instead of saying it's the active element, you have to check last user interaction. ANd if none you match focus-visible. But if someone clicked a button and there was blur you wouldn't match b/c first was not a mouse<br>
&lt;dael> emilio: What interactions count and which don't? That's an issue. I think current heuristic is fine. It's a problem on mac b/c mac doesn't focus a bunch when you click on it. A lot of programs when you click and then move focus the heuristics say button wasn't focused so new thing shouldn't mtach<br>
&lt;dael> emilio: On mac since element isn't focusable by mouse you hit this issue. Good thing to come up with something that works. Gneerally agree with proposal, but which interactions count and which don't? I want the definition to be clear<br>
&lt;dael> emilio: Does an interaction a second ago prevent programmatic focus from matching?<br>
&lt;dael> florian: Confused. Are we trying to define when a UA shows a focus ring? If not, why defining when focus-visible shows?<br>
&lt;dael> rego: Everyone is following heuristics. If we have clear heuristics then it's better<br>
&lt;dael> florian: They're supposed to be heuritstics about when they show focus ring and focus-visible matches.<br>
&lt;dael> emilio: True<br>
&lt;dael> florian: So we're talking about the combo, not getting out of sync<br>
&lt;dael> emilio: Right<br>
&lt;dael> emilio: I'm okay with the proposal. I jsut want whatever this interaction means to be clarified<br>
&lt;dael> florian: Wondering if right spec and place. I htink CSS spec has what it needs. We match browser focus ring and the pseudo class. When the browser shows focus feels more like HTML. Should we move them and call them normative?<br>
&lt;dael> emilio: It's an option. Fine with that<br>
&lt;dael> florian: If discussing state of doc and state of UI it's not a very css-y topic<br>
&lt;dael> fantasai: This text is just an example. It's not normative<br>
&lt;dael> florian: If you want normative it belongs in HTML, right?<br>
&lt;dael> Rossen_: What are we doing with this?<br>
&lt;dael> rego: Keep going on the issue and see if we should move this<br>
&lt;dael> florian: Just before we wrap up, my impression is even though called heuristisc we're trying to harmoize browsers about when they show/don't show focus ring<br>
&lt;dael> Rossen_: And make it more detectable<br>
&lt;dael> florian: We have detectable. We have the pseudo class that matches browser behavior. If we want to define browser we should have that in html<br>
&lt;dael> Rossen_: I think right next step are add any pseudo class discussions in the topic and rego will continue working with html group to see if there's additional behavior to define there<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5885#issuecomment-780722180 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 17 February 2021 17:31:41 UTC