@@ -569,7 +569,7 @@ Snapping Boxes that Overflow the Scrollport</h4>
569569 However, if the container is scrolled such that the area
570570 no longer fully fills the viewport in an axis,
571571 the area resists outward scrolling
572- until you fling out or pull it sufficiently to trigger snapping to a different <a>snap position</a> .
572+ until it is scrolled sufficiently to trigger snapping to a different <a>snap position</a> .
573573 </div>
574574
575575 Issue: Deal with case of overlapping snap areas, some of which are smaller and others larger than the viewport.
@@ -706,10 +706,7 @@ Types of Scrolling Methods {#scroll-types}
706706 UAs sometimes <dfn export>axis-lock</dfn> a scroll when its direction
707707 is sufficiently vertical or horizontal.
708708 An <a>axis-locked</a> scroll is bound to only scroll along that axis.
709- This prevents,
710- for example,
711- a <em> nearly</em> horizontal fling gesture from gradually drifting up or down as well,
712- because it is very difficult to fling in a precisely horizontal line.
709+ This prevents less-precise input mechanisms from drifting in the non-primary axis.
713710
714711<!--
715712 ██ ████████ ███████ ████████
@@ -820,9 +817,8 @@ Choosing Snap Positions {#choosing}
820817 regardless of the scroll method.
821818 For example, if the snap type is ''mandatory''
822819 and the next <a>snap position</a> is more than two screen-widths away,
823- a naïve “always snap to nearest” selection algorithm would “trap” the user
824- if they were panning with a touch gesture;
825- a sufficiently large distance would even trap fling scrolling!
820+ a naïve “always snap to nearest” selection algorithm might “trap” the user
821+ if their end position was only one screen-width away.
826822 Instead, a smarter algorithm that only returned to the starting <a>snap position</a>
827823 if the end-point was a fairly small distance from it,
828824 and otherwise ignored the starting snap position,
0 commit comments