On Tue, Oct 28, 2014 at 11:08 AM, Kip Gilbert <kgil...@mozilla.com
> Hello Jonas,
> I appreciate your detailed reviews on the topic. I'm sorry if I did
> not yet address all of your issues. Please advise if there is
> anything else I may have missed.
Thanks for your comments below. Much appreciated!
>> I guess what I'm arguing is that smooth-scrolling vs. instant
>> scrolling shouldn't be a per-element CSS property, but rather a
>> per-callsite API argument.
>> It seems to me that it will be the case that for a given element
>> you'll sometimes want to do smooth scrolling operations and
>> sometimes instant operations.
>> For example in a list of emails you might want to enable
>> smooth-scrolling down 50 emails, but if additional emails come in,
>> you want to be able to add to the top of the list and atomically
>> "add to scroll scroll position" to compensate for the added
>> I'm not sure if that means treating the current .scrollBy() and
>> .scrollLeft/.scrollTop API as instant (and make sure it applies to
>> elements in addition to windows) and adding smooth scrolling
>> versions. Or if we should add wholly new API which is more explicit
>> about if it intends to perform smooth vs. instant scrolling.
> There is an entirely new API that allows you to be explicitly specify
> if the scroll is to be smooth, instant, or to use the CSS property
> value. This was added after the original Intent To Implement email:
Awesome! I've happy to see API for this functionality.
That said, it's scary that these APIs are described in terms of
synchronous operations on the scroll position. I.e. it seems to
pretend that off-main-thread scrolling doesn't exist and then hope
that implementations are able to still create a good experience on
implementations that do off-main-thread scrolling.
That said, looking at the functions, it does seem like they address
the use cases. Though it's critical that implementations do a good job
here since otherwise there's a risk that authors will avoid them
because they result in ugly scrolling, and authors won't be able to
use feature detection to know when calling those functions will look
ugly, and when it will look good.
Though I guess if we end up with authors complaining about this, it'll
be easy to add aliases for these functions which would be easy to
>> The only use-case I could see for the CSS property would be as a
>> way to indicate if a <a href="#..."> should perform an instant or a
>> smooth scroll.
> The CSS "scroll-behavior" property now does this, in addition to
> setting the default of "smooth" or "auto" for CSSOM-View DOM scrolling
> methods. Further discussion on the CSS property value continued here:
> The CSS scroll-behavior property now has two values, "auto" and
> "smooth". "instant" was renamed to "auto", given that it selects the
> default behavior of the UA which may still scroll smoothly in response
> to user input such as keyboard scrolling and fling gestures.
I can't say I understand why it was called "auto" rather than simply
making "instant" the default value of the property. That said, if all
we're doing is bikeshedding the name I'm happy to leave it up to the