Re: [css-snappoints] Alternate Scroll Snapping Model

On Wed, Jul 22, 2015 at 12:14 PM fantasai <fantasai.lists@inkedblade.net>
wrote:

>    scroll-snap-scope -
>     Infinite causes snap edges to extend infinitely across the
>     scrollable area. Finite limits the snap edges to the actual
>     edges specified, so that e.g. boxes wholly outside the
>     viewport don't influence snapping behavior.

    (Infinite is the initial value because for single-axis
>      scrolling or gridded layouts, it doesn't matter, and
>      this is probably the more performant option for UAs.)
>
>
I am assuming 'boxes wholly outside the viewport' does not exclude boxes
that may currently be outside viewport but inertial scrolling operation
would bring them inside the viewport.


>
>    scroll-group-align -
>     Collects all snapping edges of group-snapped boxes,
>     segments them into groups that will fit within the viewport,
>     then creates snap areas that capture the specified alignment
>     of each such group. (Note that such areas may overlap, if
>     group-snapped boxes are arranged in an overlapping pattern.)
>

As I understand it the purpose of group-align is to provide pagination. I
think there is a simpler way to do this without requiring segmentation. I
am going to reuse snap-scope for this without loss of functionality but
with a slightly different naming.

scroll-snap-scope: [ inside | outside ] {1,2}
Here the snap-scope does not define the effective length of the viewport
edges (they are always infinite) but instead it identifies which descendant
edges to consider when identifying the snap target.

'inside': only edges and centers from elements that are at least partially
inside viewport are considered as snap targets. (ie. elements wholly
outside are ignored).
'outisde': only  edges and centers from elements that are at least
partially outside will be considered. (elements wholly inside are ignored)

inside => behaves similar to finite
outside => creates a pagination effect similar to group-align. Note that we
can still snap to start edge of a partially visible element.
inside outside => behaves similar infinite.

The advantage of this is that it is a simpler model and easier to
understand. The main drawback is that it does not handle the center
alignments as elegantly as the current proposal but works well for edges.

Here is the original address book example in the new model:
   :root {
       scroll-snap-type: proximity;
       scroll-snap-scope: outside;
       scroll-group-align: start;
     }
     article {
       scroll-snap-align: start;
     }


> Handling Small Viewports
> ========================
>
>    The snapped position of a box is given by its scroll-snap-align
>    property. This is a simple mapping to the current model. However,
>    if the scroll-snap-area is larger than the viewport...
>
>    * Inertial scrolling (and scroll-adjustment caused by snapping)
>      continues to align to the snap-point as normal.
>    * For explicit/programmatic (non-fling) scrolling:
>        * While the area fully fills the viewport in a given axis,
>          snapping is ignored in that axis: the container can be
>          scrolled arbitrarily and will not react.
>        * If the container is scrolled such that the area no longer
>          fully fills the viewport in an axis, the area acts as if
>          it has both-edges snapping in that axis, resisting outward
>          scrolling until you fling out or pull it sufficiently to
>          trigger snapping to a different snap-point (with either
>          proximity or mandatory behavior as appropriate).
>
> The binary distinction between zero and non-zero velocity (fling) cases is
a bit unnecessary. All we need is that if the scroll makes an element edge
visible in one axis then the edges in that axis become snap targets
otherwise they do not. So a small fling or explicit zero velocity scroll
may not cause snapping but a large one may.

Majid