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

On Fri, 03 May 2013 23:17:49 +0200, Nat Duca <nduca@google.com> wrote:

> 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.

If one wants smooth scrolling for all navigations, then a CSS property  
seems better. If one wants instant scrolling in general and just smooth  
scrolling for the "scroll to top", an API seems better.

> 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

This kind of page seems like it would benefit from having a CSS property  
that enables smooth scrolling, rather than scrolling APIs that support  
smooth scrolling. It could then use elements with id="home" and normal  
links <a href="#home">, and be done with it.

> 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.

This doesn't update the URL bar or the history, and wants to scroll an  
element into view, so scrollIntoView() seems like the best fit here.

An issue though is that plus.google.com's j/k navigation wants to position  
the post under the header, so a normal link doesn't work, and the current  
scrollIntoView() doesn't work, either (the post would be positioned behind  
the header).

We could make scrollIntoView() take an argument that supports positioning,  
which has been proposed in  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17152 but that proposal  
seems suboptimal here where we want "under the header" rather than "X%  
 from the top of the viewport".

For pages that have a fixed header, I think it would be nice to be able to  
offset navigations/scrolls to elements. For instance, we could introduce  
something like

@viewport { scroll-top-offset: 100px; scroll-left-offset: 50px; }

which would cause both <a href="#foo"> links and scrollIntoView() to  
scroll to that offset instead of the top of the viewport.

What do people think?


>>  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.

OK, that makes sense.

If we only supported the CSS property, you would then have to flip the  
value back and forth when using the j/k keys, which seems ugly.


>>  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?

I meant that Tab's proposal didn't cover all scrolling methods, and that  
supporting smooth scrolling for scrollIntoView() would be new behavior in  
implementations (it would enable smooth scrolling of multiple scrolling  
boxes, possible in different directions, at the same time). However,  
that's the case for a new CSS property that just asks for smooth  
scrolling, too.

I think it's reasonable to support smooth scrolling for scrollIntoView().


>> 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?

Did you mean offsetTop or something else?

At this point I think we should both introduce a CSS property that enables  
smooth scrolling and also support smooth scrolling with scroll() and  
scrollIntoView().

> 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. :)


-- 
Simon Pieters
Opera Software

Received on Wednesday, 15 May 2013 13:00:21 UTC