@@ -569,7 +569,7 @@ Snapping Boxes that Overflow the Scrollport</h4>
569
569
However, if the container is scrolled such that the area
570
570
no longer fully fills the viewport in an axis,
571
571
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> .
573
573
</div>
574
574
575
575
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}
706
706
UAs sometimes <dfn export>axis-lock</dfn> a scroll when its direction
707
707
is sufficiently vertical or horizontal.
708
708
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.
713
710
714
711
<!--
715
712
██ ████████ ███████ ████████
@@ -820,9 +817,8 @@ Choosing Snap Positions {#choosing}
820
817
regardless of the scroll method.
821
818
For example, if the snap type is ''mandatory''
822
819
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.
826
822
Instead, a smarter algorithm that only returned to the starting <a>snap position</a>
827
823
if the end-point was a fairly small distance from it,
828
824
and otherwise ignored the starting snap position,
0 commit comments