Re: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

[Jet Villegas]

\o/

Cross-posting to b2g-internal as these are the features the Gaia team will use for the scrolling effects requested for Firefox OS.

--Jet

----- Original Message -----
From: "Kip Gilbert" <kgil...@mozilla.com>
To: dev-pl...@lists.mozilla.org
Sent: Monday, October 27, 2014 1:31:43 PM
Subject: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

As of October 28, 2014 I intend to turn on by default CSSOM-View
Scroll-Behavior CSS Property and CSSOM-View DOM Extensions related to
smooth scrolling. They have been developed behind the
layout.css.scroll-behavior.enabled and
layout.css.scroll-behavior.property-enabled preferences. Firefox is
the first UA to ship this feature. Chrome has an implementation,
disabled by default.

Platform coverage: This will be enabled on all platforms except for
Fennec. (Fennec will be enabled once the C++ based APZC
implementation ships for Fennec)

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/d/msg/mozilla.dev.platform/mrsNyaLj3Ig/jooFD8rePzAJ

Further discussions occurred on www-style:

http://lists.w3.org/Archives/Public/www-style/2014May/0255.html
http://lists.w3.org/Archives/Public/www-style/2013May/0361.html
http://lists.w3.org/Archives/Public/www-style/2014Oct/0014.html

Bugs to turn on by default:

Bug 1087562 - Enable CSSOM-View scroll behavior CSS property by
default (Except for Fennec)

Bug 1087559 - Enable CSSOM-View scroll behavior DOM method extensions
by default (Except for Fennec)

Since the original intent to implement email, the specification has
evolved. The CSSOM-View DOM Extensions have been changed to accept
dictionaries for options and the 'instant' value for scroll-behavior
has been changed to 'auto'.

Bug: 964097 - [meta] Implement CSSOM-View smooth scrolling spec

Link to standard:

http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Jonas Sicking]

Last we talked about this, I thought that we concluded that smooth
scrolling wasn't so much a property of the element, but rather a
property of the callsite.

See my two emails to the intent to implement thread.

Did this change?

/ Jonas

[Kip Gilbert]

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.

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

http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface

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

http://lists.w3.org/Archives/Public/www-style/2014Oct/0149.html

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.

Cheers,
- Kearwood "Kip" Gilbert

[Jonas Sicking]

On Tue, Oct 28, 2014 at 11:08 AM, Kip Gilbert <kgil...@mozilla.com> wrote:
> 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
>> elements.
>>
>> 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:
>
> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-element-interface

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

>> 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:
>
> http://lists.w3.org/Archives/Public/www-style/2014Oct/0149.html
>
> 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
WG.

/ Jonas

[Robert O'Callahan]

On Wed, Oct 29, 2014 at 9:40 AM, Jonas Sicking <jo...@sicking.cc> wrote:

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

Synchronous-looking scroll operations have been part of the platform for a
long time via the scrollTop and scrollLeft properties. It does no harm to
continue and even extend support for that. There is of course no spec
requirement that we actually re-render synchronously; all we need to do is
update the script's view of page geometry synchronously. The skew between
the page's view of geometry and what we're actually rendering creates
complexity in the browser but it's something we've been dealing with for a
long time.

The new smooth-scrolling functionality is, of course, async.

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

It doesn't seem like a good idea for authors to specify "instant" and still
get smooth scrolling. And we have no good use-cases for actually being able
to force "instant" in defiance of platform/browser conventions.

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Jonas Sicking]

On Tue, Oct 28, 2014 at 1:52 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Wed, Oct 29, 2014 at 9:40 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> 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.
>
>
> Synchronous-looking scroll operations have been part of the platform for a
> long time via the scrollTop and scrollLeft properties. It does no harm to
> continue and even extend support for that. There is of course no spec
> requirement that we actually re-render synchronously; all we need to do is
> update the script's view of page geometry synchronously. The skew between
> the page's view of geometry and what we're actually rendering creates
> complexity in the browser but it's something we've been dealing with for a
> long time.
>
> The new smooth-scrolling functionality is, of course, async.

Note that I can't find *any* functions in the spec which are descried
as asynchronous.

I can only find things like, for example, element.scrollBy(), which is
defined in terms of reading scrollTop/scrollLeft, adding the value the
arguments passed to the function, and then calling element.scroll().
Such an implementation strategy would result in ugly UI which would
not satisfy the use cases that were brought up in the other thread.

Of course, an implementation can completely ignore the specification
text. And instead look at just the WebIDL part of the spec and then do
something better.

But it still doesn't seem like a great state of affairs.

/ Jonas

[Robert O'Callahan]

On Fri, Oct 31, 2014 at 5:35 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> Note that I can't find *any* functions in the spec which are descried
> as asynchronous.
>
> I can only find things like, for example, element.scrollBy(), which is
> defined in terms of reading scrollTop/scrollLeft, adding the value the
> arguments passed to the function, and then calling element.scroll().
> Such an implementation strategy would result in ugly UI which would
> not satisfy the use cases that were brought up in the other thread.
>

http://dev.w3.org/csswg/cssom-view/#concept-smooth-scroll
Scripted smooth scrolls let the user-agent control the timing of the
scroll. Thus, we can make them as asynchronous as we want.

[Jonas Sicking]

On Thu, Oct 30, 2014 at 1:55 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Oct 31, 2014 at 5:35 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Note that I can't find *any* functions in the spec which are descried
>> as asynchronous.
>>
>> I can only find things like, for example, element.scrollBy(), which is
>> defined in terms of reading scrollTop/scrollLeft, adding the value the
>> arguments passed to the function, and then calling element.scroll().
>> Such an implementation strategy would result in ugly UI which would
>> not satisfy the use cases that were brought up in the other thread.
>
> http://dev.w3.org/csswg/cssom-view/#concept-smooth-scroll
> Scripted smooth scrolls let the user-agent control the timing of the scroll.
> Thus, we can make them as asynchronous as we want.

That doesn't cover use cases like:

"Adjust the scroll position down by 10 pixels atomically with the next
reflow since I just added a 10 pixel element at the top of the page"

Please see the text from the previous thread that Kip quoted, and the
API that he linked to.

Another use case that I know we've talked about is supporting
drag'n'drop where the user drags something to the bottom of the screen
in order to have the screen scoll up so that the content can be
dropped further down. For example drag'n'drop of icons on the
homescreen.

Has that usecase been verified to be solved by the current API?

/ Jonas

[Jonas Sicking]

Another use case that's not well supported by the current spec text is
"smoothly scoll down by 50 pixels". The way you'd do that is to call
element.scrollBy({ top: 50, behavior: "smooth" }). However that
function call is defined as synchronously getting .scrollLeft from the
main thread, which means that you might perform an entirely different
scroll.

/ Jonas

[Robert O'Callahan]

On Fri, Oct 31, 2014 at 11:32 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> Another use case that's not well supported by the current spec text is
> "smoothly scoll down by 50 pixels". The way you'd do that is to call
> element.scrollBy({ top: 50, behavior: "smooth" }). However that
> function call is defined as synchronously getting .scrollLeft from the
> main thread, which means that you might perform an entirely different
> scroll.
>

That's true. I guess you want a third behavior for scrollBy, say "async",
to handle this case. Oddly enough this actually matches a behavior we have
internally. I believe that would handle the other cases you mentioned too.

[Jonas Sicking]

On Thu, Oct 30, 2014 at 3:55 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Oct 31, 2014 at 11:32 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Another use case that's not well supported by the current spec text is
>> "smoothly scoll down by 50 pixels". The way you'd do that is to call
>> element.scrollBy({ top: 50, behavior: "smooth" }). However that
>> function call is defined as synchronously getting .scrollLeft from the
>> main thread, which means that you might perform an entirely different
>> scroll.
>
> That's true. I guess you want a third behavior for scrollBy, say "async", to
> handle this case. Oddly enough this actually matches a behavior we have
> internally. I believe that would handle the other cases you mentioned too.

Couldn't we simply change the defined behavior of element.scrollBy({
top: 50, behavior: "smooth" }) such that it sends the delta
coordinates to the composition thread, and adds the current scroll
position there instead of on the main thread?

Having a scrollBy function which doesn't actually scroll the current
position by the given delta seems like asking for trouble.

/ Jonas

[Robert O'Callahan]

On Fri, Oct 31, 2014 at 12:02 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> Couldn't we simply change the defined behavior of element.scrollBy({
> top: 50, behavior: "smooth" }) such that it sends the delta
> coordinates to the composition thread, and adds the current scroll
> position there instead of on the main thread?
>

OK, we should allow that.

We'd still need the "async" behavior for your other use-cases.

[Jonas Sicking]

On Thu, Oct 30, 2014 at 4:06 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Oct 31, 2014 at 12:02 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Couldn't we simply change the defined behavior of element.scrollBy({
>> top: 50, behavior: "smooth" }) such that it sends the delta
>> coordinates to the composition thread, and adds the current scroll
>> position there instead of on the main thread?
>
>
> OK, we should allow that.
>
> We'd still need the "async" behavior for your other use-cases.

Which use-case do you need "async" for?

The "Adjust the scroll position down by 10 pixels atomically with the

next reflow since I just added a 10 pixel element at the top of the

page" use case could be supported using

element.scrollBy({ top: 10, behavior: "instant" });

as long as the spec is clearly defined to apply that at the time of
the next reflow. Again, the main thing lacking is spec text rather
than API.

At least assuming we don't run into problems with ability to feature
detection. But I don't think "async" helps with that.

There is the drag'n'drop case though. I don't have a mental model for
how to solve that. Maybe "async" could help with that, but I don't
quite understand it's proposal.

/ Jonas

[Robert O'Callahan]

On Fri, Oct 31, 2014 at 7:21 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> Which use-case do you need "async" for?
>
> The "Adjust the scroll position down by 10 pixels atomically with the
> next reflow since I just added a 10 pixel element at the top of the
> page" use case could be supported using
>
> element.scrollBy({ top: 10, behavior: "instant" });
>
> as long as the spec is clearly defined to apply that at the time of
> the next reflow. Again, the main thing lacking is spec text rather
> than API.
>

I don't think you want to define it as "the time of the next reflow". "The
time of the next reflow" is not defined or referenced in any spec and I
suspect we don't want it to be.

I think it makes sense for "instant" to be synchronous, to match existing
scrolling APIs and because I think there are use-cases for that.

[Kartikaya Gupta]

On 30/10/2014, 19:02, Jonas Sicking wrote:
> Couldn't we simply change the defined behavior of element.scrollBy({
> top: 50, behavior: "smooth" }) such that it sends the delta
> coordinates to the composition thread, and adds the current scroll
> position there instead of on the main thread?

FYI we filed bug 959793 ages ago for this (well, without the behaviour
stuff).

kats