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

On Wed, Feb 26, 2014 at 7:03 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Feb 27, 2014 at 11:25 AM, Rick Byers <rbyers@chromium.org> wrote:
>
>> We're currently focused (eg. see [1]) on low-level mechanisms that give
>> framework developers more flexibility to customize the behavior while
>> scrolling.  We imagine a world where frameworks can implement a wide
>> variety of effects like snap points without needing any new APIs and the
>> associated web-standards efforts.  For example, the "hidey bars" that slide
>> and snap in and out in while scrolling in the Twitter app for Android share
>> some similar properties to snap points, but can't be implemented directly
>> with such a high-level proposal.  We don't yet have a specific proposal
>> that would enable scenarios like snap points and "hidey bars", but hope to
>> in the near future.
>>
>
> What do those "hidey bars" share with snap-points other than activity
> being triggered at the end of a scroll gesture? Does platform support for
> them require anything other than an event firing at the beginning or end of
> a scroll gesture?
>

First I should say that I'm not 100% sure.  We haven't yet built fully
polished versions of these sorts of UI components for the web, but we plan
to try (pull down to refresh is our next big step - http://crbug.com/328503).
 I'd love to hear from anyone that's built effects like these.  That said,
I'm personally thinking about it like this:

Ideally snap points and hidey bars both would track browser-defined scroll
physics, and alter that physics in some way at the end of a scroll gesture.
 For example as you're flinging past a snap point, or flinging out of a
partially-displayed hidey bar.  Ideally we'd smoothly transition from the
browser-defined fling curve into the component-defined 'snap' physics.  For
hidey bars this is more apparent (and probably only significant) at very
slow fling velocity - the bars start as completely position-locked to the
scrolling background (like position: sticky - hard to implement in JS for
UAs with threaded scrolling), but at some point gradually start sliding to
their fully visible or fully invisible position.  In practice we may be
willing to settle for something simpler that doesn't share as much with
snap points (but still shares the scroll-position-linked effect with other
things like parallax scrolling and pull to refresh).

Today the only way someone can really implement these sorts of effects (at
least in Chrome) is to re-implement all of scrolling (which means the
physics likely no longer match the platform default).  We think being
competitive with native mobile platforms means we must do better and enable
frameworks to innovate here while still leveraging the browser's support
for scrolling.


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