W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-snappoints] Alternate Scroll Snapping Model

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 22 Jul 2015 16:32:40 -0700
Message-ID: <CAAWBYDBHJSMi+Fx9Cxuoc-qLG6oJRgo3icBhoUwbNCWO_L+Uqg@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC