Re: [css-snappoints] Alternate Scroll Snapping Model

On Wed, Jul 22, 2015 at 3:53 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Jul 23, 2015 at 9:21 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> 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>.)
>
>
> FWIW I don't think we should maintain snapping when layout changes. It's
> hard to implement, has nasty edge cases (e.g., what do you do if the element
> you're snapping to is removed), and (as discussed previously on this list)
> it's incompatible with scroll APIs that ignore snapping (which we will very
> likely need to add). We could have a state flag controlling whether we're
> tracking layout updates, and temporarily turn that flag off in these
> situations, but that's ugly. I don't see that tracking layout is a good idea
> in any case; it feels like it could easily lead to bad user experiences
> where scrolling jumps around unintuitively. If we create API to perform
> snapped scrolling (which we also should), then the effect can largely be
> emulated by authors as needed.

Also, I just realized that it doesn't work in the first place.  If the
x and y snapping are coming from different elements, following them
around is terrible.

~TJ

Received on Wednesday, 22 July 2015 23:33:27 UTC