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

Re: [css-snappoints] Alternate Scroll Snapping Model

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 23 Jul 2015 10:53:27 +1200
Message-ID: <CAOp6jLab3as6xJjANFEt1N6TLPn5iZMteST6-yfiSUGj2SEDSg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
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.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
Received on Wednesday, 22 July 2015 22:53:54 UTC

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