- 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>
On Tue, 19 Mar 2013 18:46:03 +0100, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > 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