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

I think there's a fundamental trade-off here between control and
future-proofing.  Eg. using low-level input events to implement UI
affordances give you more control, but using higher-level APIs like :active
and onfocus provides better consistency and future-proofing for new input
types (eg. accessibility input systems).

The way this works out on other (more successfully layered) platforms is
that the platform ships both the low level APIs and some higher level
libraries built on top of them.  Most developers target the higher level
libraries because they're easier to use, provide consistency, and do more
of the work for them.  But when they decide they really must punch down to
the lower level library, they have that choice (perhaps even by forking a
component from the high level library) but take on more of a maintenance
burden.  When lots of developers find they have to reach down to the low
level for some scenario, the platforms libraries are eventually updated to
support that scenario at the higher level.  So in successfully layered
platforms new features tend to trickle down from apps, to standard
libraries that ship with the platform, to influencing the kernel APIs.

I'd apply this to our scenario here by saying we should aspire to a future
where browsers can ship a standard library that implements your snap point
API in terms of low level APIs.  We'd still encourage web developers to use
the high level APIs for exactly the reasons you mention, but when they need
some fix/improvement they can take on the burden of supplying the library
themselves (perhaps only for certain UAs).  This is obviously not on the
near-term roadmap for the web platform, but there are lots of incremental
steps towards this aspirational goal.  Eg., in blink perhaps we ensure we
have the APIs to make some framework successful shipping their own snap
points library, and then (once we've proven it works with the performance
we want) we also implement your CSS API.  Ideally we'd find some way to
share some code between the two implementations (see [1] for a start at
this for blink), but that could come later.

Reasonable people can of course disagree on this.  We've never really
approached the web platform like this before, so it's no surprise that it
sounds a little crazy and different browsers will prioritize the different
approaches differently (see for example our focus on the low-level enabling
technologies of web components over the past several years).

Rick

[1]
https://docs.google.com/a/chromium.org/document/d/13cT9Klgvt_ciAR3ONGvzKvw6fz9-f6E0FrqYFqfoc8Y/edit



On Thu, Feb 27, 2014 at 4:45 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> 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
>