Re: [css-snappoints[ CSS snappoints update

On Wed, Oct 8, 2014 at 8:53 AM, Matt Rakow <marakow@microsoft.com> wrote:

> Sorry I missed this, didn’t hit my email rules.
>
> I'm glad to hear Mozilla is still interested in shipping snap-points --
> after the declaration from Google that they aren't interested in the
> properties I've certainly focused less on this area.


I just want to clarify our current thinking here.  We are VERY interested
in these scenarios, and I think a CSS API like you've defined is reasonable
and will certainly be convenient for authors.  However we feel it's more
important long-term to fix the limitations in the platform that prevent
framework developers from fully succeeding in building these effects
today.  If we can make some progress on the bigger picture problems here, I
think we'd also be interested in implementing this API for the most common
scenario.

In particular, the problems with the traditional approach to implementing
snap points in JavaScript (eg. driven by touchmove events) include:

   - Requires code for each type of input device that can trigger scrolling
   - Don't work with native scrollbars
   - Doesn't compose properly with other scrolling effects - eg.
   showing/hiding of browser top controls (vertical)
   - Hard to make the scroll physics match the platform

Here's a rough demo exploring a different approach to implementing snap
points in JS with a different set of tradeoffs: http://goo.gl/dlg1nN.
Basically is does native scrolling but adds/subtracts some additional
momentum during momentum scrolling. This mostly addresses the problems
above, but has different problems:

   - Needs an abstract method to detect the end of "active scrolling"
   (currently works only for touch events)
      - eg. maybe add a simple "isActive" property on scroll events for
      this?
   - Velocity estimation is too difficult / error-prone
      - eg. maybe add a simple API for requesting accurate instantaneous
      scroll velocity?
   - Fling destination estimation and curve combination is difficult /
   platform-specific
      - eg. maybe add a simple API for requesting the target scroll
      position during momentum scroll?
   - Can get UI artifacts when scrolling and JS are not synchronized
      - This is obviously the big one - and so where we've been focusing
      our work / debate.
      - In Chrome, our "best-effort sync scroll"
      <https://plus.google.com/+RickByers/posts/b4QrYp6vWCY> feature means
      this often isn't a major problem
      - But we think we still need some sort of API to provide guarantees
      here (eg. our scroll-delay proposal, or a mechanism for running
JavaScript
      on a thread that IS synchronized with scrolling).

  If Mozilla is still interested I'm happy to pick this back up as an
> active project.
>
> Thanks,
> -Matt
>
>
> -----------------------------------------------------------------------------------
>
> From: Jet Villegas W3C [mailto:w3c@junglecode.net]
> Sent: Friday, October 3, 2014 11:31 AM
> To: Robert O'Callahan
> Cc: www-style
> Subject: Re: CSS snappoints update
>
> The Mozilla bug for this feature:
> https://bugzilla.mozilla.org/show_bug.cgi?id=945584
> As Rob noted, our implementation work has advanced to the point that we'd
> like to clarify the normative descriptions prior to shipping in Firefox.
> --Jet
>
> On Wed, Oct 1, 2014 at 7:58 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> People at Mozilla would like to make some progress on a spec, because we'd
> like to ship something.
>
>
> A couple of things have changed since the last go-around:
> 1) It's become clear that the previous model we had where snap-points
> depended, in part, on the direction of a scroll gesture, was a mistake. So
> that brings us closer to consensus.
> 2) Some use-cases which some people wanted CSS snappoints to solve (e.g.
> scripted smooth scrolling by a whole page) can now be satisfactorily solved
> using CSSOM APIs, e.g. element.scrollBy({ left:..., behavior:"smooth").
> I still think a case has not been made for scroll-snap-points-x/y to
> support any value other than "elements", so we should get rid of it.
> I think scroll-snap-coordinate should allow specifying the type of box
> used (margin or border-box, at least) as well as an offset from the edge of
> that box.
> I still think that scroll-snap-coordinate and scroll-snap-destination are
> terrible names.
> I'm worried that there are loads of outstanding issues noted in the draft
> but there have been no edits since March :-(.
>
> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.
>
>