Repository navigation
[focusgroup] i18n: should arrow key navigation follow text direction? #522
Description
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 | rtlwriting-mode: horizontal-tb | vertical-rl | vertical-lrAnd they combine, giving 6 possible configurations that influence where "next" content appears.
If it's deemed impractical to follow
writing-modeor 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'sdirectionandwriting-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.)
Activity
gregwhitworth commentedon May 3, 2022
@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 commentedon Nov 8, 2022
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 commentedon Nov 17, 2022
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 commentedon Oct 2, 2023
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 commentedon Feb 21, 2024
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
resizeproperty, and sets a good precedent to follow here.travisleithead commentedon Feb 21, 2024
Current plan:
focusgroupshould 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).css-meeting-bot commentedon Feb 22, 2024
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
[focusgroup] Clarify i18n arrow key directionality mapping (#1011)
aphillips commentedon Mar 19, 2024
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 commentedon Mar 21, 2024
Re-opening based on @aphillips desire for additional review
github-actions commentedon Sep 18, 2024
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.
janewman commentedon Jun 4, 2026
The latest version of this handles all of the typical ways content is re-ordered, focus follows the visual ordering, e.g. left moves visually left, up moves visually right, etc.
for example, see: https://open-ui.org/components/scoped-focusgroup.explainer/#reading-flow
aphillips commentedon Jun 4, 2026
@janewman The text looks good to me. It's careful to avoid "text selection", which is where directional cursoring gets tricky. I will recommend that I18N's tracker be closed.