W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-snappoints] Blink team position on snap points

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 28 Feb 2014 10:45:46 +1300
Message-ID: <CAOp6jLZMrMKRfaKr+mHjgeWeuFaO_sCuYh8b=wOu_FDjj3-BPw@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>
Cc: "www-style@w3.org" <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adam Barth <abarth@chromium.org>, Nathaniel Duca <nduca@chromium.org>
OK. I think that's a good goal, but I don't know how reachable it is and I
guess you don't either yet.

Replicating our implementation of CSS scroll-snapping in script is
possible, given sufficient new DOM APIs, but it sounds hard to me for a
couple of reasons.

Our implementation works with all kinds of scroll gestures --- mousewheel,
keyboard input, scrollbar interaction, touch panning and touch flinging. It
can be extended to work with any new scroll gestures that emerge in the
future. To get the same flexibility in script would require completely new
scrolling events that are gesture-independent. However, the actual behavior
we implement is specific to each gesture. For example, when pressing the
down-arrow key, we are willing to scroll somewhat further than a line to
reach a snap-point. But when pressing the page-down key, we prefer not to
look for snap-points further than the normal page-scroll distance because
we don't want to lose context by scrolling more than a full page. So the
challenge is to ensure that scripts written today can produce ideal
snapping behavior for all scroll gestures on all platforms, including those
that haven't been invented yet. One approach would be to devise a
vocabulary of logical scroll operations (e.g., "scroll by N lines, scroll
by page, continuous pan", etc) and try to map all current and future scroll
gestures onto it, but that introduces a risk that the approach may break
down in the future because the vocabulary is inadequate, and CSS
scroll-snapping avoids such a risk.

Another issue is that our implementation snaps to the edges of CSS
fragments, e.g. the border-box edges of elements with "scroll-snap-edges:
border-box" and the margin-box edges of elements with "scroll-snap-edges:
margin-box". To implement this properly in script can't even be done with
CSSOM APIs implemented today, and even with new APIs like getBoxQuads it
will be tricky. Performance will be an issue since you potentially have to
examine the geometry of a very large number of elements.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w
Received on Thursday, 27 February 2014 21:46:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC