W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-snappoints] Alternate Scroll Snapping Model

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 22 Jul 2015 14:21:45 -0700
Message-ID: <CAAWBYDBOnHCyH-UdL1=hNWODWrRBreiSvf8t2Kfqyt7QogOZ4Q@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, Jul 22, 2015 at 12:10 PM, fantasai
<fantasai.lists@inkedblade.net> wrote:
>   1. Defining <box> = [ border-box | margin-box ] || column-box
>      to have multicols also provide snap lines between columns?

Or we could just bite the bullet and define a ::column pseudo-element.
We can define that this is the only property that applies initially.

>   2. Shifting scroll-snap-type to the descendants?
>      (Initial value = proximity. Regions between a mandatory point
>      and proximity points would be mandatory.)

I think it's clumsy/weird to mix proximity and mandatory snaps, for
the reason you give here (between a mandatory and proximity
snap-point, the region is effectively infinity; you only get proximity
behavior between two proximity snap-points).  I'd prefer to keep it on
the container.


So I think we got the definition of edge vs center snapping wrong, at
least in finite snapping.  (fantasai and I just discussed this in

* A center-snapped element want to align a point of itself with a
point in the viewport.  This is a 2d movement.
* An edge-snapped elements wants to align an edge of itself with an
edge in the viewport.  This is a 1d movement (but both axises can do
it, independently).

These two are in conflict: center-snapping considers the element as a
whole in 2d, selecting a single winning element to align;
edge-snapping considers the element as two independent 1d requests,
and doesn't care whether the winning x and winning y come from the
same or different elements.

To cast them together:

1. Find the minimum x and minimum y displacement among all the edge-snaps.
2. Find the minimum euclidean displacement (d) among all the center-snaps.
3. If d < sqrt(x² + y²), center snap. Otherwise, edge-snap.

We *could* be a little more correct and find the x/y pair with the
minimum euclidean displacement, but that's quadratic in the number of
edges.  The algorithm given above is linear, and will usually select
the minimum displacement; when it doesn't, it's at least close.


fantasai also just brought up that we should probably maintain the
snapped position when layout changes, "remembering" which center/edge
we snapped to and preserving that snap as the element changes position
on the screen.  We shouldn't *reevaluate* snapping until there's
actually scroll movement, tho.  (This is in response to roc's second
constraint, at the bottom of


We're also not sure that we need infinite snapping at all.  Why is it
*ever* good to align to things well outside the viewport?  Every
use-case given so far fits in the viewport.

~TJ (and fantasai)
Received on Wednesday, 22 July 2015 21:22:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC