W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [cssom-view] Add a "smooth" parameter to scrollTo and scrollBy functions

From: Simon Pieters <simonp@opera.com>
Date: Tue, 19 Mar 2013 22:30:31 +0100
To: "www-style list" <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Nat Duca" <nduca@google.com>, "James Simonsen" <simonjam@chromium.org>, "Tony Gentilcore" <tonyg@google.com>, "Tom Wiltzius" <wiltzius@google.com>
Message-ID: <op.wt7p05m8idj3kv@simons-macbook-pro.local>
On Tue, 19 Mar 2013 18:46:03 +0100, Tab Atkins Jr. <jackalmage@gmail.com>  

> I'm forwarding a request from some of our internal engineers here, but
> I think it's a good idea myself. ^_^
> Apparently, there has been a significant rise in the number of sites
> desiring "smooth" scrolling when adjusting the scroll position of a
> page.  Right now, they're limited to some fairly hacky, bad solutions,
> akin to standard Javascript transitions - run a requestAnimationFrame
> and update scrollTop in increments.
> This is problematic for several reasons.  For one, it's janky, slow,
> and power-intensive, just like all javascript-controlled animations.
> Moving a lot of these types of transitions/animations to CSS has been
> a huge win on several fronts, and it would be nice to extend this same
> win to scrolling.
> For two, it's difficult to get the subtleties of the behavior down
> correctly.  If somebody uses their mousewheel during the transition,
> for example, you want to stop the transition immediately and scroll
> from that point as appropriate.  Expecting authors to get this kind of
> behavior right every time is unrealistic, and if they don't, users
> have a bad experience.
> For three, it requires a layout, even when you're just doing a
> scrollBy to move the page downward by 10px, because you have to
> measure offsetTop.
> Because of this, I believe we should address the problem directly, and
> add a method to say that a given instant-scroll should be "smooth"
> rather than instant.
> There are a few ways we could do this.  One early idea was to make a
> CSS property, like scroll-transition, that controlled this.  I don't
> think this is a good idea - I can see good reasons to want both
> instant and smooth scrolling on the same element in different
> circumstances, which argues that the decision should be made at the
> scroll site, not the element.
> Thus, I propose that we amend the existing scrollTo and scrollBy
> functions in CSSOM View to take a third parameter: an optional
> "smooth" string.  If omitted, the scroll is instant.
> This achieves the desired behavior at a minimal cost.  In downlevel
> clients, the scroll would still work, but would be instant instead of
> smooth, which is the same desirable failure mode that transitions have
> today.
> Thoughts?

Is there no desire to control how long it should take to scroll? Is there  
no desire to control the timing function (ease/linear/etc)?

Simon Pieters
Opera Software
Received on Tuesday, 19 March 2013 21:30:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:27 UTC