Re: [css-snappoints] Alternate Scroll Snapping Model

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
person).

* 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
<https://wiki.mozilla.org/Gecko:CSSScrollSnapping>.)

---------------------

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