[focusgroup] i18n: should arrow key navigation follow text direction?

[fvsch]

The Focusgroup explainer currently states:

up/right moves focus forward, down/left moves focus backwards

I’m wondering if different locales change cultural expectations for what is "forward" and what is "backwards". I’d expect that in Arabic or Hebrew, "forward" is left (not right).

My understanding is that CSS has 2 properties influencing text direction:

• direction: ltr | rtl
• writing-mode: horizontal-tb | vertical-rl | vertical-lr

And they combine, giving 6 possible configurations that influence where "next" content appears.

If it's deemed impractical to follow writing-mode or even CSS layout modes that impact content flow direction (flex-direction, grid stuff…), should this proposal at least make room for ltr/rtl text direction?

[bkardell]

relevant related tabs research here I guess https://open-ui.org/components/tabs.research.parts#directionality-mirroring.

[travisleithead]

It makes a lot of sense to me to have "forward/backward" map to typical conventions which can be configured with HTML's dir, etc., and CSS's direction and writing-mode. I do worry about potential inconsistencies when authors might force a subtree into a particular direction different from the root's directionality. Perhaps (for consistency) only the root element's configuration should be accepted in terms of establishing a document-wide convention to avoid weirdnesses around the transition point in the markup?

In any case, here's a first-attempt:

	horizontal-tb	vertical-rl	vertical-lr
LTR	⬅=prev, ⬆=prev, ➡=next, ⬇=next	⬅=next, ⬆=prev, ➡=prev, ⬇=next	⬅=prev, ⬆=prev, ➡=next, ⬇=next
RTL	⬅=next, ⬆=prev, ➡=prev, ⬇=next	⬅=next, ⬆=next, ➡=prev, ⬇=prev	⬅=prev, ⬆=next, ➡=next, ⬇=prev

I think the logical interpretation of "horizontal" and "vertical" should be independent of these above mappings and continue to constrain left/right under the term "horizontal" and top/bottom under the term "vertical".

[travisleithead]

In testing Bidi text with Window's "notepad" application, the caret movement does seem to support this next/prev notion, though it seems counter-intuitive to the "logical" direction of the arrow:
⬅=move caret to the right (which is "previous" in RTL Bidi text order)
➡=move caret to the left (which is "next" in RTL Bidi text order)

[tabatkins]

We can state this more simply by saying that the default (unconstrained) focusgroup behavior associates the four arrows with "previous" or "next" depending on whether they point in the "block/inline-start" or "block/inline-end" directions on the focusgroup element associated with the currently-focused element.

In testing Bidi text with Window's "notepad" application, the caret movement does seem to support this next/prev notion, though it seems counter-intuitive to the "logical" direction of the arrow:

That seems opposite to what we want, no? It looks like those directions are purely "left = prev, right = next", which produces the observed counter-intuitive motion in RTL text. (In bidi situations where the visual direction flip-flops within the document, you have to choose one direction or the other, so you'll get the counter-intuitive motion for text in one direction or the other, and that's fine. But we shouldn't mess this up for single-language markup with a known direction.)

[travisleithead]

This issue has been transferred to the Open UI CG's issue tracker as openui/open-ui#522