[css-ui-4] Make directional navigation more composable

[frivoal]

The definition of Directional Focus Navigation says (among other things) this:

If the focus is navigated to an element that was not otherwise focusable, it becomes focusable only as the result of this directional navigation, and the :focus pseudo-class matches the element while it is focused as such.

Note: there were other options under consideration for such "not otherwise focusable" elements, including focus to the next otherwise focusable element in the document tree (including descendants of such a not otherwise focusable element). Input on such other options is welcome and explicitly solicited, especially from implementation experiences and author experience using the directional navigation properties in their content.

Making an element focusable, as the spec currently requires, is not useful: if there's no event handler attached to it the element, then focusing it doesn't get you anything. And if If there is, then the element should be made focusable anyway (via tabindex=0 or what have you), regardless of directional navigation. We mostly landed on that behavior for accidental historical reasons, rather than due to usecases: this was what the Presto implementation happened to do, and sticking with it meant less friction on our way along TR, especially since Presto was no longer updated. However, this kind of rationale is only reasonable if there is no use case either way and we just need to pick something for consistency.

But there are use cases arguing the other way, and the behavior suggested by the note is much more useful: when the target isn't focusable, search from there in document order for the first focusable element, and focus that instead. Modern web pages are often built out of components (web components, react components or angular components...), and the top embedding page should be able to treat them as black boxes. Being able to target the top level element of the component, and letting document order (with potential overrides as discussed in #1764) deal with the rest would go a long way.

See https://github.com/lgeweb/spatial-navigation/blob/master/explainer.md#current-approach for an example of worry about the current lack of composability (cc @jihyerish ).

[robdodson]

could we instead make the properties define local spatial navigation (e.g. between components) while allowing components to determine navigation behavior inside of themselves?

This sounds like the behavior you would want. For instance, you might embed a complex component, like a WYSIWYG editor, into a page. The WYSIWYG editor may implement spatial navigation in a way that's really useful within the confines of the component itself, but perhaps different from how the user wants to navigate the page as a whole.

[css-meeting-bot]

The Working Group just discussed https://github.com/w3c/csswg-drafts/issues/1910.

The full IRC log of that discussion

<florian> Topic: https://github.com//issues/1910
<gregwhitworth> jcraig: this will fail on its own in the weeds
<astearns> github: https://github.com//issues/1910
<gregwhitworth> florian: one of the weird things that we have with arrow keys, it lets you define where you should focus to
<gregwhitworth> florian: what happens if the element where you want to go to isn't focusable
<gregwhitworth> florian: what is currently defined is that if the user wants to go there we should make it focusable
<gregwhitworth> florian: these days many/most are built are out of components
<gregwhitworth> florian: this may allow the browser to go the "right" and then seek for the first focusable element
<gregwhitworth> florian: if you're the author you can point to what's there, if your using a component and you don't know what's there maybe a heuristic is better
<gregwhitworth> tantek: as an author you may want to use a seamless iframe but you don't know what's on the other side. I don't think we can determine the best behavior
<gregwhitworth> tantek: since you mentioned components, I think we shouldn't be solving this in isolation
<gregwhitworth> florian: I'm not disagreeing with what you state, I'm not sure how that answers my question
<gregwhitworth> tantek: I'm saying this discussion doesn't belong in CSSWG
<gregwhitworth> smfr: so are you saying these props don't belong in CSSUI
<gregwhitworth> smfr: to me, it sounds like spacial navigation would be in its own spec rather than here in its own naïve form
<gregwhitworth> florian: do you think there is a potential case where the focusable behavior is what you would want?
<gregwhitworth> tantek: very unlikely
<gregwhitworth> florian: I think searching inside of that makes sense and is uncontroversial
<gregwhitworth> tantek: you're asking about something n the weeds and I'm not sure it helps/hurts and I think we should move this to a different arena
<gregwhitworth> astearns: is anyone lining up to implement this improvement, then I think there would be a case to make a change to the spec
<gregwhitworth> astearns: if this is just an academic change, what's the point?
<robdodson> (sorry for speaking out of turn) but the notion of creating focus "groups" seems to already exist today with Shadow DOM. jsbin.com/lidaguf/edit?html,output
<gregwhitworth> florian: the fact that, it works poorly when you have blackbox component which was mentioned by Blink
<gregwhitworth> tantek: I don't think it's experimental
<gregwhitworth> astearns: *reads rob's comment*
<gregwhitworth> robdodson: the notion of focus groups kind of exists already, that will allow once focus is within that shadow root boundary
<gregwhitworth> robdodson: the notion of the grouping kind of exists if you're willing to use shadow dom
<tomalec> AFAIK, Shadow DOM also propagates, kind of scoped focus, to elements distributed via `<slot>`
<tantek> issue filed: https://github.com//issues/1948
<gregwhitworth> florian: what I was thinking of trying to specify if you focus that non-focusable element - if there is tabindex, etc use that
<tantek> I mean GH issue filed https://github.com//issues/1948
<tantek> " [css-ui-4] Spatial Navigation needs a new home in WICG #1948 "
<gregwhitworth> florian: since we don't seem to have consensus can I suggest a lighter one to make a change to what we agree is stupid"
<gregwhitworth> ???: What do we all agree is stupid?
<gregwhitworth> ???: Currently you only seem to say that you should look for tabindex
<gregwhitworth> florian: or is a button, etc
<astearns> s/???/bradk/
<gregwhitworth> florian: it seems very weird to me that something is focusable will take you to something that isn't focusable but with a tab key you can't
<gregwhitworth> florian: that's weird
<gregwhitworth> astearns: since we're not closing, let's table the issue for now

[robdodson]

@alice shared this in our IRC chat today. It's a link to the bit of the Shadow DOM spec that describes how focus moves into a shadow root and finds the first focusable element.
https://www.w3.org/TR/shadow-dom/#x5.2-focus