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

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.

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

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?

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.

Thanks,
-Matt

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

Received on Thursday, 27 February 2014 19:25:03 UTC