Re: [css-snappoints] Alternate Scroll Snapping Model

On Sun, Aug 2, 2015 at 5:27 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Since Matt hasn't brought it up I guess I'll have to ask the obvious
> question: given Trident, Webkit and Gecko have shipped or are close to
> shipping something very close to the current draft, why do you think it's
> worthwhile making significant changes at this point?

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

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.

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.

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!)

It's possible that at this point we've implemented ourselves into a
corner, and we're stuck with a suboptimal solution due to shipping
implementations.  It's still possible to retrofit our spec onto Matt's
spec, it just results in less-optimal names for some properties.  In
particular:

* scroll-snap-type is common between the two specs. No change necessary.
* Use scroll-snap-coordinate/destination instead of scroll-snap-align.
The naming isn't ideal, but it's also not *terrible*.  Just
longer/more complex words than I like.  *-coordinate gains the "group"
keyword for invoking grouping.
* Drop scroll-snap-points-x/y if possible; their only purpose is to do
the container-defined snap lines, which I think we generally agree
aren't actually that useful.  If we do end up wanting to keep it,
sure, whatever, it doesn't *harm* anyone, it's just an unnecessary and
slightly weird part of the model.
* Add the rest of the properties from our spec.

...it's actually easier to merge than I thought.  Cool.

~TJ

Received on Thursday, 6 August 2015 23:48:21 UTC