RE: [css-snappoints] Alternate Scroll Snapping Model

> 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?

> 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? 

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

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.

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

Thanks,
-Matt

[1] http://lists.w3.org/Archives/Public/www-style/2015Jul/0457.html

Received on Friday, 7 August 2015 00:53:24 UTC