[css-scroll-snap-1] Change the scroll categories to absolute/relative/stationary, per WG resolution. w3c#12394

Author: tabatkins

css-scroll-snap-1/Overview.bs

@@ -914,7 +914,7 @@ Scroll Snap Limits: the 'scroll-snap-stop' property {#scroll-snap-stop}
     Animation type: discrete
     </pre>
 
-    When scrolling with an intended direction,
+    When performing a [=relative scroll=],
     the <a>scroll container</a> can “pass over” several possible <a>snap positions</a>
     (that would be valid to snap to,
     if the scrolling operation used the same direction
@@ -941,7 +941,7 @@ Scroll Snap Limits: the 'scroll-snap-stop' property {#scroll-snap-stop}
             it must instead snap to the first of this element's <a>snap positions</a>.
     </dl>
 
-    This property has no effect on scrolling operations with only an <a>intended end position</a>,
+    This property has no effect on non-[=relative scrolling=] operations,
     as they do not conceptually “pass over” any <a>snap positions</a>.
 
 Snapping Mechanics {#snap-concepts}
@@ -976,18 +976,22 @@ Snapping Mechanics {#snap-concepts}
 Types of Scrolling Methods {#scroll-types}
 ------------------------------------------
 
-    When a page is scrolled,
-    the action is performed with
-    an intended end position
-    and/or an intended direction.
-    Each combination of these two things
-    defines a distinct category of scrolling,
-    which can be treated slightly differently:
+    There are many ways to cause a page to scroll,
+    and they differ in their intent,
+    which affects how scroll snapping and other features
+    should <em>respond</em> to them.
+    The types of scrolling intents are:
 
-    : <dfn export>intended end position</dfn>
+    : <dfn export>absolute scroll</dfn>
     ::
+        An [=absolute scroll=] is a scrolling operation
+        that is not intended to have any relation with the previous scroll position.
+        Whether the new position is before or after the previous scroll position
+        is not relevant to the operation;
+        the scroll container just "goes straight there".
+
         <div class="example">
-            Common examples of scrolls with only an <a>intended end position</a> include:
+            Common examples of [=absolute scrolls=] include:
 
             * a panning gesture,
                 released without momentum
@@ -998,28 +1002,64 @@ Types of Scrolling Methods {#scroll-types}
             * homing operations such as the <kbd>Home</kbd>/<kbd>End</kbd> keys
         </div>
 
-    : <dfn export>intended direction and end position</dfn>
+        Note: Scroll snapping responds to an [=absolute scroll=] 
+        by finding the nearest valid [=snap position=],
+        <em>regardless</em> of direction.
+
+    : <dfn export>relative scroll</dfn>
     ::
+        A [=relative scroll=] is a scrolling operation
+        that does have a meaningful relation with the previous scroll position;
+        that is, the fact that the new scroll position is before or after the old scroll position
+        is an important quality of the scroll.
+
+        Relative scrolls might or might not have an intended end position,
+        but they always have an intended <em>direction</em>.
+
         <div class="example">
-            Common examples of scrolls with both an <a>intended direction and end position</a> include:
+            Common examples of [=relative scrolls=] with both an intended direction and end position include:
 
-            * a “fling” gesture,
-                interpreted with momentum
+            * a “fling” gesture, interpreted with momentum
             * programmatically scrolling via APIs such as {{Window/scrollBy()}}
             * paging operations such as the <kbd>PgUp</kbd>/<kbd>PgDn</kbd> keys (or equivalent operations on the scrollbar)
+
+            Common examples of [=relative scrolls=] with only an intended direction include:
+
+            * pressing an arrow key on the keyboard
+            * pressing an arrow button on the scrollbar
+            * a swiping gesture interpreted as a fixed (rather than inertial) scroll
         </div>
 
         The intended end point of the scroll prior to intervention from features such
         as snap points is its <dfn noexport>natural end-point</dfn>.
 
-    : <dfn export>intended direction</dfn>
+        Note: Scroll snapping responds to a [=relative scroll=]
+        by finding the nearest valid [=snap position=]
+        <em>in the intended direction</em> (if possible),
+        so a snapped element can't get "trapped"
+        when the [=snap positions=] are far apart.
+
+    : <dfn export>stationary scroll</dfn>
     ::
+        A [=stationary scroll=] is a scrolling operation
+        that isn't "intending" to move the scroller at all;
+        instead, it's attempting to keep something stationary
+        (usually, an element you're focusing on).
+
         <div class="example">
-            Common examples of scrolls with only an <a>intended direction</a> include:
+            Common examples of [=stationary scrolls=] include:
 
-            * pressing an arrow key on the keyboard (or equivalent operations on the scrollbar)
-            * a swiping gesture interpreted as a fixed (rather than inertial) scroll
-        </div>
+            * scroll anchoring with 'overflow-anchor',
+                when off-screen content changes size
+                and would move the current anchor
+            * scroll snapping (especially ''scroll-snap-type/mandatory'')
+                when another element changes size
+                and causes the scroller to no longer be at a valid snap point
+        </div> 
+
+        Note: Scroll snapping responds to a [=stationary scroll=]
+        by finding the nearest valid [=snap position=],
+        similar to an [=absolute scroll=].
 
     Additionally, because page layouts usually align things vertically and/or horizontally,
     UAs sometimes <dfn export>axis-lock</dfn> a scroll when its direction
@@ -1065,8 +1105,8 @@ Choosing Snap Positions {#choosing}
         on the scroll position,
         <a>snap positions</a> should be ignored if their elements are far outside of the “corridor”
         that the <a>snapport</a> defines as it moves through the <a>scrollable overflow area</a>,
-        or a hypothetical “corridor” in the direction of a scroll with only an <a>intended direction</a>,
-        or the <a>snapport</a> after an scroll with only an <a>intended end position</a>.
+        or a hypothetical “corridor” in the direction of a [=relative scroll=],
+        or the <a>snapport</a> after an [=absolute scroll=].
 
     * User agents <em>must</em> ensure that a user can “escape” a <a>snap position</a>,
         regardless of the scroll method.
@@ -1079,7 +1119,7 @@ Choosing Snap Positions {#choosing}
         and otherwise ignored the starting snap position,
         would give better behavior.
 
-        (This implies that a scroll with only an <a>intended direction</a>
+        (This implies that a [=relative scroll=] without an intended end position
         must always ignore the starting <a>snap positions</a>.)
 
     * If a page is navigated to a fragment that defines a target element
@@ -1092,7 +1132,7 @@ Choosing Snap Positions {#choosing}
 
     * If a scroll by page operation (e.g. Page down / Page up) is being performed,
         eligible <a>snap positions</a> that require scrolling less than or equal to the size of the <a>optimal viewing region</a> of the <a>scroll container</a>
-        should be selected before any farther away, ignoring the starting <a>snap positions</a> so that progress is still made in the <a>intended direction</a>.
+        should be selected before any farther away, ignoring the starting <a>snap positions</a> so that progress is still made in the intended direction.
 
 <h4 id="multiple-aligned-snap-areas">Selecting between multiple aligned snap areas</h4>