[CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API

# Frédéric Wang (a year ago)

This email is to announce that I have started to work on (programmatic) smooth scrolling in WebKit from the CSSOM View specification [1]. To use this effect, web developers can pass a behavior parameter (auto, smooth, or instant) to Element.scroll, Element.scrollTo, Element.scrollBy, Element.scrollIntoView, Window.scroll, Window.scrollTo or Window.scrollBy [2]. When behavior is auto, the instant/smooth characteristic is actually taken from the value of a new CSS scroll-behavior property [3]. This new feature will be protected by a compile flag (enabled by default) and a runtime flag (an experimental feature). If you are interested, you can follow advancement on Bugzilla [4].

Incidentally (and since that was convenient to do it before) I also added some basic support for new ScrollIntoView options [5] [6] that allow to specify how you want the revealed element to be aligned with respect to its scrollable ancestors.



[1] drafts.csswg.org/cssom-view [2] drafts.csswg.org/cssom-view/#dictdef-scrolloptions [3] drafts.csswg.org/cssom-view/#propdef-scroll-behavior [4] bugs.webkit.org/show_bug.cgi?id=188043 [5] bugs.webkit.org/show_bug.cgi?id=189258 [6] drafts.csswg.org/cssom-view/#dictdef

Contact us to advertise here
# Frédéric Wang (a year ago)

The main implementation is now submitted for review at: bugs.webkit.org/show_bug.cgi?id=188043

It has some issue with smooth scrolling via scrollIntoView on nested scrollers but I don't plan to work on this until the main part is merged. See bugs.webkit.org/show_bug.cgi?id=189907

# Frédéric Wang (5 hours ago)

Cathie has taken over my work on this. In order to facilitate review, we decided to split the patch into three parts. If there is no opposition, we'll probably go ahead and land (1) and (2) below. But in any case, we need approval from Apple reviewers on (3).

(1) Introduce CSS/IDL changes under a new preference flag bugs.webkit.org/show_bug.cgi?id=205009

I already r+ed this part and I think Simon Fraser had reviewed this part
before so I don't expect it to be controversial. The only question is
whether it makes sense to land this before the rest of the

implementation is done. I guess it is ok to take it with (2) in any case.

(2) Implement a generic animator class running in the scrolling thread, based on the one that already exists on GTK for smooth scrolling. bugs.webkit.org/show_bug.cgi?id=204882

Simon has also partially reviewed this piece and modulo minor changes I
think it looks good to me too. The issue here is that I'm not sure I

should review it given I wrote most of this code. Also, it's probably not the most efficient approach and ports should probably rely on any existing platform API to animate scrolling when available. However, it is a necessary fallback and the preference flag is turned off for now, so I think it is safe to take this for now...

(3) Implement scroll animator in the UI process for iOS, based on native platform support (UIScrollView). bugs.webkit.org/show_bug.cgi?id=204936

This part hasn't been reviewed yet although the general design has been
discussed with Simon. Alternatively, this patch can be taken before (2)
since the two are more or less independent and each one really only

depends on (1).

I'm interested to hear about suggestions to rely on native scroll animations for other ports. However, this can probably be done in follow-up patches. Web developers really requested support on iOS and it seems very important to have (3) for that port.

Thank you,

Want more features?

Request early access to our private beta of readable email premium.