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

I think the idea is that you define an animation with curve, time etc, but
it is possible to "scrub" through the animation using touch events.

Like you can define something like the Android notification drop-down by
defining the show-animation, but the drop down it initiated by a touch
swipe down, and first when the finger is lifted, it will continue the
animation - from the point the finger is lifted, using the remaining time
(given animation curve and position) and animating from the right position
of the animation curve.

It might also be possible to interrupt the animation by putting your finger
on the drop down while animating. This works on Android phones today, so
try it out to see what I am talking about.

Kenneth


On Thu, Feb 27, 2014 at 8:24 PM, 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.
>
> 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.
>
>


-- 
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆