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

On Mon, Mar 3, 2014 at 2:59 PM, Matt Rakow <marakow@microsoft.com> wrote:

> >From: rbyers@google.com [mailto:rbyers@google.com] On Behalf Of Rick
> Byers
> >Sent: Thursday, February 27, 2014 2:16 PM
> >To: robert@ocallahan.org
> >Cc: www-style@w3.org; Tab Atkins Jr.; Adam Barth; Nathaniel Duca
> >Subject: 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.
>
> Aside from future-proofing and support across input types, performance is
> one of the key benefits of snap points.  You can already see what a script
> implementation of snap points is like today on many "parallax" websites,
> and the performance is terrible.  These sites are disabling
> native/independent panning and running script before, during, and after the
> gesture on every frame to control animation curves and scroll offsets.  I
> agree that extensible APIs to cover a wider range of scenarios could be
> nice, but if the end result is "the page controls the scroll from script"
> I'm skeptical that the performance will match user expectations of an
> independent pan.  By contrast, a declarative model like snap-points allows
> us to fully handle the manipulation on an independent thread, with high
> confidence about the responsiveness that the user will see regardless of
> what script is running.
>
> Perhaps I'm not quite understanding the feature you're describing, but my
> expectation is that even with low-level APIs and well-built libraries you
> won't see satisfactory panning performance, especially on low-end and
> mobile devices.


Yes, that is the key issue (and the primary reason I was gung-ho on snap
points earlier, and also pointer-events/touch-action).  The question is
whether reliable 60fps performance is possible on at least mid-range mobile
devices without offloading all animations/scrolling to another thread.  I
don't know the answer, but our approach has shifted recently from assuming
it's not, to making a serious effort to try to show that it can be.

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