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

On Thu, Feb 27, 2014 at 11:24 AM, Matt Rakow <marakow@microsoft.com> wrote:

> I took a look at the Google+ app on iOS to learn what hidey bars are
> (thanks for the pointer Rick!) -- I think this is the same effect that you
> can see on the Bing Image Search results page [1], minus the "at some point
> gradually start sliding to their fully visible or fully invisible
> position".  Please let me know if I'm missing an aspect of the design.
>

Another good example is the Twitter app on Android.  In that app, there are
hidey bars both on the top and bottom of the scrollable region.  Notice
that hidey bars on the top need to be pixel exact because their bottom edge
moves at the same speed and in the same direction as the scrollable
contents.


> Based on this, I think the main distinction between snap points and the
> sort of features you're referring to is that snap points fall into the
> category of "altering scrolling", whereas hidey bars, parallax,
> pull-to-refresh, etc. are "altering content based on scrolling."
>

Pull-to-refresh also alters scrolling physics.  When pulling to refresh,
the scrollable region does not move one pixel for every pixel the user's
finger moves.  Instead, the scrollable region moves at a slower rate the
further the user over scrolls to give the impression of elasticity.


> Hidey bars in particular I think bear the closest resemblance to
> position:sticky, in that they have an acceptable bounds to be within and
> their precise position is dependent on motion of the viewport.  The only
> difference is that instead of "stay motionless w.r.t. the viewport unless
> you'd violate your acceptable bounds (which are defined in document
> space)," they use the inverse: "stay motionless w.r.t. the scrolling
> background unless you'd violate your acceptable bounds (which are defined
> in viewport space)."  Maybe this would make more sense to be considered in
> css-position?
>

They're certainly related to position sticky.  I wouldn't say that what
you've described is the only difference however.  For example, position
sticky doesn't have any "settling" behavior, in which the hidey bars end up
either completely open or completely closed after the user lifts their
finger.

Something like:
> <div class="hideyBarBounds" style="position:fixed; width:100%;
> height:200px; top:-100px;">
>     <div class="hideyBar" style="position:lazy; width:100%; height:100px;">
>
> For the automatic hiding/showing of halfway visible bars, I think this is
> either achievable with a timeout or an event as Robert mentions.  In either
> case, I don't think it's necessarily related to snap points.
>

Indeed, these effects are not necessarily related to snap points.  That's
the point.  Rather than tiling the space of effects with declarative
mechanisms, we're more interested in letting framework authors invent
new-and-exciting scroll-linked effects.  Instead of hard coding snap points
into the platform, we'd rather the platform was powerful enough that
framework authors can implement snap points themselves.

As Rick stated, we're not opposed to this working group pursuing snap
points.  We're just letting you all know that we have no plans to implement
them anytime soon.

Adam



> [1] http://www.bing.com/images/search?q=cats
>
>
> >From: rbyers@google.com [mailto:rbyers@google.com] On Behalf Of Rick
> Byers
> >Sent: Thursday, February 27, 2014 6:40 AM
> >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
> >
> >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.
>
>