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

Hi Simon. Sorry for the delayed reply, and some responses inline.

On Tue, Apr 16, 2013 at 12:43 AM, Simon Pieters <simonp@opera.com> wrote:
>
> Apparently, there has been a significant rise in the number of sites
>> desiring "smooth" scrolling when adjusting the scroll position of a
>> page.
>>
>
> Do you have URLs to such sites I can look at?


Pinterest has a scroll to top, in their main feed. I've seen similar around
the web.

Another case is "side nav causes scrolling." Try out the navigation links
on the right hand side of
http://www.milwaukeepolicenews.com/#menu=stats-page

Similarly, I've seen a lot of the social sites that support j/k style
navigation between posts do this: plus.google.com and the tumblr feed I'm
pretty sure do it.


>  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,
>>
>
> Can you elaborate on the good reasons? Do you know of a site that does
> both instant and smooth scrolling on the same element?


I don't have a strong opinion here, myself, though you could imagine a
scenario where your designers want a window.popState or hashchange to do
immediate scrolling versus j/k keys to do smooth scrolling.


>
>
>  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.
>>
>
> CSSOM View has more scrolling members than these. In particular,
> element.scrollIntoView(), which is more complex than scrollTo/scrollBy. If
> we just support smooth scrolling for scrollTo/scrollBy, you still need to
> use offsetTop to know how much to scroll if you want to scroll to a
> particular element.
>

Is the correct way to interpret your reply that "we should also have smooth
on the these members as well?" Or are there semantic issues that came to
mind for you with having a smooth transition for some of the view methods?


>
> Also, if you want your links to use smooth scrolling rather than instant
> scrolling, you have to cancel the `click` and run scrollIntoView() (if we
> support that), and also use history.pushState if you want the URL bar to
> show the new fragment (without scrolling to it instantly). This seems like
> a huge overhead and likely to be buggily implemented by authors compared to
> just setting a CSS property asking for smooth scrolling.


Thats a totally fair point. Is your intuition that making offsetTop
transitionable is a more comprehensive solution? Again, I dont have strong
opinions here, my main desire is for something so that when people do these
effects, it can be buttery smooth. :)