Rename Navigation to Movement for consistency, update feature flag name

Author: sambandaru

Editing/bidi-visual-order-caret-navigation-explainer.md

@@ -1,11 +1,11 @@
-# Visual Order Caret Navigation for Bidirectional Text
+# Visual Order Caret Movement for Bidirectional Text
 
 ## Authors
 
 - Samba Murthy Bandaru (sambamurthy.bandaru@microsoft.com)
 
 ## Participate
-- Feature request: [Visual order caret navigation for bidi text](https://issues.chromium.org/issues/499819853)
+- Feature request: [Visual-order caret movement for bidi text](https://issues.chromium.org/issues/499819853)
 - Spec: [Selection API -- `Selection.modify()`](https://w3c.github.io/selection-api/#dom-selection-modify)
 - [Chromium editing-dev group](https://groups.google.com/a/chromium.org/g/editing-dev)
 
@@ -48,7 +48,7 @@ This makes the current caret movement visually inconsistent:
 
 This behavior is confusing and disorienting, particularly for users who routinely work with bidirectional content.
 
-This explainer proposes implementing **visual caret navigation** in Chromium -- arrow key movement that always follows the on-screen direction, so that Right moves the caret rightward and Left moves it leftward regardless of text or line direction. The feature will be gated behind a feature flag for incremental rollout.
+This explainer proposes implementing **visual caret movement** in Chromium -- arrow key movement that always follows the on-screen direction, so that Right moves the caret rightward and Left moves it leftward regardless of text or line direction. The feature will be gated behind a feature flag for incremental rollout.
 
 ## The Bidirectional Text Problem
 
@@ -96,15 +96,15 @@ Visual movement solves this by moving the caret based on its **screen position**
 
 4. **Gate behind a feature flag** for safe incremental rollout, with no behavior change for users who do not opt in.
 
-5. **Correctly handle all bidi scenarios**: simple LTR/RTL boundaries, multiple bidi runs, nested bidi embeddings, bidi control characters, CSS `direction`/`unicode-bidi` overrides, and cross-line navigation.
+5. **Correctly handle all bidi scenarios**: simple LTR/RTL boundaries, multiple bidi runs, nested bidi embeddings, bidi control characters, CSS `direction`/`unicode-bidi` overrides, and cross-line movement.
 
 ## Non-Goals
 
 1. **Changing selection extension behavior.** Shift+Arrow selection operates on logical DOM offsets. True visual selection across bidi boundaries would require multi-range selection support in Chromium, which does not exist today. This is a potential future extension but is out of scope.
 
 ## Proposed Solution
 
-When the `BidiVisualOrderCaretNavigation` feature flag is enabled, Chromium's arrow key handling switches to visual (screen-order) caret movement. The implementation works by leveraging Blink's existing inline layout fragments, which are already stored in visual display order after bidi reordering. This allows the algorithm to walk through text in the order it appears on screen rather than the order it is stored in memory.
+When the `BidiVisualOrderCaretMovement` feature flag is enabled, Chromium's arrow key handling switches to visual (screen-order) caret movement. The implementation works by leveraging Blink's existing inline layout fragments, which are already stored in visual display order after bidi reordering. This allows the algorithm to walk through text in the order it appears on screen rather than the order it is stored in memory.
 
 At a high level:
 
@@ -135,7 +135,7 @@ With this feature enabled, `'left'` and `'right'` will perform true visual movem
 
 The feature is currently gated behind a disabled-by-default runtime flag:
 
-- **Command line:** `--enable-blink-features=BidiVisualOrderCaretNavigation`
+- **Command line:** `--enable-blink-features=BidiVisualOrderCaretMovement`
 
 **Rollout phases:**