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

To follow up from this old thread, we've just started a discussion over on
www-dom ("Enabling scroll customization") for one approach to allow
frameworks to implement effects like snap points in JavaScript:
http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0134.html.

We're going to be experimenting with ideas like this in blink behind a
flag, but we of course want feedback on the design tradeoffs (and ideally
consensus from the community and a W3C standard) before we ship anything.
I think once we've enabled frameworks to build such rich effects on top of
primitives, then we'd be interested in also implementing the most common UI
features (like snap points and position: sticky) directly in blink to avoid
the need to pull in a library for the most common cases.

Note that one motivation for this approach (but certainly not our only one)
is Google's material design (
http://www.google.com/design/spec/material-design/introduction.html).
There are a number of scroll-linked effects that will be shipping in mobile
apps which are currently impossible to do properly on the web.  But these
are sufficiently special case, that I really don't think we want to have
discussions in CSSWG about adding new CSS properties that are relatively
specific to material design (Google would probably have a completely new
design spec by the time any such standards reached REC anyway <grin>).
We're starting work on prototypes and demos and so expect to make this much
more concrete in the coming months.

Rick


On Mon, Mar 3, 2014 at 4:52 PM, Rick Byers <rbyers@chromium.org> wrote:

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