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

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-ui-4] Make directional navigation more composable ==
[The definition of Directional Focus Navigation](https://drafts.csswg.org/css-ui-4/#nav-dir) 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 https://github.com/w3c/csswg-drafts/issues/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 ).




Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1910 using your GitHub account

Received on Friday, 27 October 2017 07:42:29 UTC