8000 [css-ui-4] Make directional navigation more composable · Issue #1910 · w3c/csswg-drafts · GitHub
Skip to content

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

@frivoal

Description

@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 ).

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions