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

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

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

>

Received on Monday, 3 March 2014 20:00:19 UTC