Re: [css-snappoints] Alternate Scroll Snapping Model

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