[css-nav-1] Make things focusable in CSS

[frivoal]

---

Migrated from WICG/spatial-navigation#25
Originally created by @frivoal on Fri, 16 Feb 2018 06:41:17 GMT

---

Other specs (most likely HTML) will probably find it convenient if we define a hook in the "Handling key presses" section to let them define what a particular element does when arrow keys are pressed and that element wants to respond (e.g. the <select> element changing which is the currently selected <option>).

EDIT: The discussion in this issue moved to a completely different, and more interesting topic. Repurposing the issue to talk about that.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @bkardell on Thu, 05 Apr 2018 13:12:11 GMT

---

I don't think i am, but i can call in

On Thu, Apr 5, 2018, 3:18 AM Florian Rivoal notifications@github.com
wrote:

@bkardell https://github.com/bkardell Are you attending the Berlin F2F
of the CSS-WG?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
WICG/spatial-navigation#25 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA1IZa-RFvvmICkDZRd3Ux27L1k9FZRwks5tlcU0gaJpZM4SH73N
.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @hugoholgersson on Tue, 13 Mar 2018 07:50:03 GMT

---

@bradkemper it sounds like we had the same idea :) Did you see my comment?

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @bradkemper on Mon, 12 Mar 2018 05:52:38 GMT

---

Maybe something like focusable: [tab | arrows | none].

Or maybe focusable: [main | secondary | none], to account for keyboardless navigation.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @frivoal on Wed, 28 Mar 2018 12:26:58 GMT

---

I agree with all the above, and will happily repeat similar arguments to any CSSWG member who disagrees.

I still have some doubts that makes we wonder if making things focusable in CSS is the right thing to do or not:

pointer-events or display:none can hide/deactivate things from CSS for clicking / focusing purposes. I haven't though too much about it, but for the reasons you list above, I don't think I would have an issue with a property that can remove focusability from things that have it. However, that's not what you're proposing. You're proposing adding focusability from CSS to things that don't have it.

I am more skeptical about that because I believe that adding focusability alone is generally not useful, and that you typically need to also add some event handler to do something useful when the now focusable element is focused / activated. That will be done in JS, not in CSS. So that makes me think that making things focusable should also be in JS, to avoid things getting out of sync.

For me, it is a matter of separation of concerns in the sense of putting together the things that are tightly coupled together, not in the sense of separating presentation from style.

However, if there is a reasonable use case for making things focusable and then attaching no additional behavior at all via JS, then it seems OK to have it in CSS.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @frivoal on Tue, 20 Mar 2018 03:33:04 GMT

---

@bradkemper This is not at all what I planned to be doing with this issue, but I wasn't clear, and this is more important topic than the original one :D

I wasn’t clear from the prose whether spacial-navigation: active was supposed to make an element navigable by arrows, or if it was something that applied to an ancestor.

It was meant to be applied to ancestors, so that's a separate thing. (and it's probably going to be dropped or pushed to the next level anyway, see WICG/spatial-navigation#35)

I’ve been trying to get to in some of my other comments, is a way to specify, in CSS, that an element can be tabbed to or arrowed to (previously imagined as tab-index:0 and arrow-index:0).

Maybe something like focusable: [tab | arrows | none].

This issue has come up before in the CSSWG. I think last time the rough conclusion was that although selectors may be a convenient way to set this up, there was no strong coupling between focusability and style, while there was strong coupling between focusability and semantics (i.e. HTML/DOM) and between focusability and attached behaviors (JS/DOM).

The fact that this isn't about styling isn't a blocker in my mind, but and selectors are a nice mechanism. But the fact that it doesn't seem to be strongly coupled with style does make me question whether it belongs in CSS.

I think it would be very interesting if we could restart that discussion (here or even better in the CSSWG) base on use cases that support:

• why markup/DOM or a js API isn't the right place for that kind of switch
• why we need to distinguish between tab focusing vs arrow focusing

Since you've been working on that sort of things, do you think you could write these down?

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @bradkemper on Mon, 12 Mar 2018 04:46:58 GMT

---

I’m not sure if this is where you want this comment. But what I’ve been trying to get to in some of my other comments, is a way to specify, in CSS, that an element can be tabbed to or arrowed to (previously imagined as tab-index:0 and arrow-index:0).

Maybe something like focusable: [tab | arrows | none].

I wasn’t clear from the prose whether spacial-navigation: active was supposed to make an element navigable by arrows, or if it was something that applied to an ancestor. But if I was creating a component, like say, something that acted like radio buttons, then I would need to say when something could be tabbed to, and when something could only be arrowed to. So, something like this, I guess:

div.radio-group { spatnav-container: create; }
span.radio-button { focusable: arrows; }
span.radio-button.checked,
span.radio-button:first-child:not(:has(+ .checked)) { focusable: tab; }

(That last line only works declaratively if :has() is usable on the Web. Otherwise, would have to use JavaScript to track when there are no “checked” classes on the buttons, and set a separate class to indicate that on the radio group parent).

Is there some other way to achieve this using the spec properties?

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @bradkemper on Sat, 17 Mar 2018 16:31:48 GMT

---

@hugoholgersson I have now. Yes, seems pretty similar.

As someone who has recently been adding keyboard and AT usability to pop up menus, nav dropdown menus, light boxes, etc., my view is that being able to easily control WHICH elements are focusable or not (via CSS) is a more urgent problem than any of the rest.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @bradkemper on Wed, 21 Mar 2018 16:57:16 GMT

---

@frivoal I think it might be a distinction without a difference. The only interactivity difference I can see between changing focus between controls and changing focus (or whatever you’d call it) within a control, is what key you use to do it.

Pragmatically, when building a UI component, '.focus()', ':focus', and '.setAttribute("tab-index", "0|-1") are the tools I use now if I want to follow best keyboard practices for navigating controls like radio buttons, menus, tabs, trees, and the like, where the internal thing has to be focused before it can be changed. I’d have a hard time thinking of that as anything other than focus.

Please see this, if you haven’t already: https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#kbd_general_within

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @bradkemper on Wed, 21 Mar 2018 00:14:57 GMT

---

@frivoal let me get back to you on that, when I have time to be more complete. Mostly because it would be sooooo much easier and probably more performant to use the CSS engine and CSS rules, rather than complicated fiddling with adding and removing and changing tabindex attributes every time a key is pressed or focus changes. I know I’m near the boundary line at the edge of what CSS is for, but so is the 'resize' property, and so are the other things being discussed. I want to move the line, if needed, to be able to use CSS in this hugely beneficial way.

@hugoholgersson for component-like things, I want to be able to do what native elements do with keyboard control. Which means that when you tab to a radio button, menu, etc., then you can use arrow keys to move focus within it, or tab to exit the component. So, that is two different levels of focusing.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @hugoholgersson on Tue, 20 Mar 2018 15:54:53 GMT

---

Do we need to distinguish navigation methods? I doubt authors would like to disable one but not the other...

Perhaps focusable: auto | none is enough to begin with? That should be future-compatible with whatever (spatial) navigation method we come up with next.

[frivoal]

---

Migrated from WICG/spatial-navigation#25 (comment)
Originally created by @frivoal on Wed, 21 Mar 2018 01:50:37 GMT

---

I agree there's a fuzzy border, and last time this was discussed in the csswg, I was the one pushing for it, so I'm sort of with you on that one. The questions I listed above are the ones that would help convincing me (and hopefully others) that we're on the correct side of the fuzzy border.

As for "2 levels of focusing" withing native elements, I'm still confused on this one (really, not pretending to be confused just to be polite while disagreeing): is that indeed a form of focusing that needs to respond to some keys but not others for usability's purpose, or is that something else than focusing ("selection"? that word is already used for text selection), somewhat more akin to changing the state of a control than changing which control has the focus? I don't have a good answer, nor a clear idea on how to get to an answer. Help figuring this out (possibly with copious amount of examples) much appreciated.