RE: [css-snappoints] Alternate Scroll Snapping Model

On Aug 6, 2015 17:52, "Matt Rakow" <marakow@microsoft.com> wrote:
>
> > The current spec does not address what happens to elements larger than
the viewport, and can't (afaict) be modified to do so in any elegant way.
It's based around snapping a point to a point, which is incompatible with
being able to pan around inside an element (without introducing new
concepts that are duplicating the changes we've made in our proposal).
>
> I don't particularly consider this a goal of the spec.  It's always been
possible for authors to shoot themselves in the foot with element sizing
relative to their containing scroller and making content inaccessible (e.g.
so many fixed-position fixed-width toolbars!).  Why would this not be the
responsibility of the author's layout to guarantee that the containing
scroller always provides an appropriately-sized view into the content, or
inversely appropriately-sized content for the scroller?

Because it's impossible for the author to predict that, *and* there are
perfectly acceptable use-cases for having elements larger than the viewport
but still snapping (large images, large social media posts, etc) (the
author shouldn't have to apply a max-height:100% and overflow: auto just to
use scroll snapping in a non-hostile manner), *and* CSS should and does
worry about authors acting naively and writing code without thinking about
all users, and when possible makes things still work to some extent.

> > The current spec only handles well the case of snapping elements which
entirely fill the non-scrolling axis, or at least don't have any neighbors
in the non-scrolling direction.  Again, this is because it's based around
snapping a point to a point.  This is incompatible with, for example,
having a Facebook or G+ feed with several columns of elements, where all
you want is for the viewport to proximity-snap to the top of one of the
elements.
>
> The Facebook feed is a single column that doesn't have any neighbors in
the non-snapping axis (or is there some new interface I haven't seen yet)?
Why would the current spec not work well for this scenario with proximity
points on each story?

Facebook has or had an interface for something that was two columns, with
entries not aligned. G+ uses multiple unaligned columns based on your
screen size.

> > Even when there's a linear feed of content in the scrollable area, if
their snap coordinates aren't exactly lined up, it'll cause the element to
"jiggle" back and forth as it seeks out snaps to successive points.  This
isn't too hard to do accidentally, because you're require to specify a 2d
point on the element that the container is snapping to.
>
> This is only possible if you're assuming a 2D-scrollable region
containing a linear feed of content, which is less common.  Typically
you'll have a 1D scroller with 1D content, or a 2D scroller with 2D
content.  In any case I don't see how Elika's suggestions make it any
easier to align points than the current spec provides for.

All scrollable regions are 2d scrollable. (Possibly with the brand-new
exception of elements with 'clip' on one axis.)

In the commonest case it will indeed work fine (all elements using their
top left corner), but it's not hard to accidentally screw this up.

> Is the concern that scroll-snap-destination describes a point in 2D space
rather than a separate X and Y destination, thereby forcing the author to
specify an offset on the non-scrolling axis?  The original spec specified a
separate X and Y destination (scroll-snap-axis-x and scroll-snap-axis-y)
but was changed to point-based notation per feedback from the WG.  Some of
the recent discussion has brought up splitting certain properties back into
a longhand again for single-axis snapping [1 and linked references] which
would be applicable here, but needs more thought.

Yes, that's the issue.

> > There is no way to address "group" snapping, which we feel is an
important use-case.  It should be useful for the Facebook/G+ feed case,
where you have a lot of content scattered across the screen in 2
dimensions, and scrolling by "page" is useful.  Similarly for the
image-gallery use-case given in the spec, if the images are small enough
that multiple can fit on the viewport at once.  Heck, I would love it if
text articles used group snapping on their paragraphs; I
> > *hate* scrolling and getting a partial line at the top, so scrolling by
"whole page, at paragraph boundaries" would be *amazing*.  (Poor man's
paged scrolling!)
>
> What is "group" snapping?  I haven't heard this concept brought up before
this thread and a thorough definition would be helpful.

It's defined in the OP to this thread. You collect elements into page-sized
groups and snap the groups, rather than individual elements. It's like
scroll-snap-points:repeat(100%), but actually responds to content and acts
better in general.

~TJ