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

[travisleithead]

This issue has been transferred from MicrosoftEdge/MSEdgeExplainers#514
@fvsch opened this issue on 2021-09-09

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 commented on 2021-09-16

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

@travisleithead commented on 2021-09-28

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 commented on 2021-09-29

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 commented 2021-10-21

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

[gregwhitworth]

@travisleithead let me know if this is ready for agenda. I think a summary of the options would be of value. I've also labeled it so that the i18n team can see it and weigh in.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[matial]

As a Bidi user, I am used to the Notepad behavior where left-arrow is Prev and right-arrow is Next where the paragraph direction is LTR and vice-versa where the paragraph direction is RTL.. Note that other apps may behave differently.
However it is the position of the Israel Bureau of Standards (standards SI5194 and SI5858) that the arrow keys should move visually, i.e. right-arrow always move to the right, left-arrow to the left, etc... It is useful to also have key combinations for the logical functions Next and Prev, but they are distinct,

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[travisleithead]

Issue #870 recommends adding 'inline' and 'block' for logical movement (which should be the recommended approach IMO), where 'horizontal' and 'vertical' are for physical movement. This matches the behavior of the CSS resize property, and sets a good precedent to follow here.

[travisleithead]

Current plan:

• Add the logical properties proposed in focusgroup should support logical properties #859 to the explainer (approve PR Add logical property support to proposed focus-group-direction #870). These behave as recommended in this issue: e.g., arrow keys advance the focus in the DOM according to the focusgroup element's current computed direction and writing mode ("forward" == toward the inline/block-end direction, "reverse" == toward the inline/block-start direction).
• Recommend the use of the logical properties over the physical properties for best i18n experience by default.
• Update all examples in the explainer where directionality is specified to use the logical properties.

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] i18n: should arrow key navigation follow text direction?.

The full IRC log of that discussion

<gregwhitworth> Travis: a couple of key points does right arrow key change with text direction or not
<gregwhitworth> Travis: there is plenty of evidence in 522 and 859 should follow the direction of the content
<masonf> q+
<gregwhitworth> Travis: so if you're in RTL then the left arrow key would move you "forward" and we shoudl adopt that
<gregwhitworth> Travis: there is also an issue with horizontal and vertical as a value to limit which values are possible
<gregwhitworth> Travis: already a PR to introduce logical properties and would of course just go with the flow of the content
<luke> q+
<gregwhitworth> ack masonf
<brecht_dr> q+
<gregwhitworth> masonf: just one clarification, I think you should follow the direction of the text. Is the focusgroup elements direction or the element you're on?
<gregwhitworth> masonf: you can end up in a scenario where you bounce back and forth
<gregwhitworth> ack luke
<gregwhitworth> luke: one thing I question with this, should we just make logical be the other physical values?
<gregwhitworth> luke: I think the absolute physical values are almost always the wrong thing to do
<gregwhitworth> luke: they exist in CSS due to history
<gregwhitworth> luke: maybe that's wrong but I can't think of a reason to use physical properties
<gregwhitworth> luke: I agree with the focusgroup being where the writing mode direction is derived
<gregwhitworth> Travis: sounds good, thank you
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: first off thank you and +1 to it being the focusgroup container
<gregwhitworth> brecht_dr: it should probably be logical only
<gregwhitworth> brecht_dr: there are older websites and platforms that only use hacks primarily for floats and change direction in other stylesheet you can end up in a danger zone?
<gregwhitworth> brecht_dr: I'm unsure but wanted to raise it

[aphillips]

I18N has added this issue to our agenda for our 2024-03-21 call. Keyboard cursor behavior is known to be complicated in a bidi context and we want to ensure that your text resolves this. None of us, to my knowledge, has reviewed #1011 yet.

[gregwhitworth]

Re-opening based on @aphillips desire for additional review

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.