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

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

From: Kenneth Rohde Christiansen <kenneth.r.christiansen@intel.com>
Date: Tue, 19 Mar 2013 19:37:37 +0100
Message-ID: <CAEC208usM9c7QxTM1aCSc+27yzMvj++dHdyoXyTn-3o6t2iquA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>, Nat Duca <nduca@google.com>, James Simonsen <simonjam@chromium.org>, Tony Gentilcore <tonyg@google.com>, Tom Wiltzius <wiltzius@google.com>
I think it is a really good idea, and pretty simple to implement.

Kenneth

On Tue, Mar 19, 2013 at 6:46 PM, 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?
>
> ~TJ
>



-- 
---------------------------------------------------------------------
Intel Denmark Aps
Langelinie Alle 35, DK-2100 Copenhagen
CVR No. 76716919

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Received on Tuesday, 19 March 2013 18:38:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:07 GMT