Intent to Experiment: document.rootScroller

294 views
Skip to first unread message

David Bokan

unread,
Jan 6, 2017, 3:35:28 PM1/6/17
to blink-dev, Dima Voytenko
Contact emails

Spec

Summary
The document element (body in Chrome) has some special powers that other scrollers do not. For e.g. only scrolling in the <body> element hides the URL bar and shows overscroll glow.

document.rootScroller allows an author to give these powers to an arbitrary scroller, allowing iframes and divs to control the URL bar. This makes composing multi view apps significantly easier. See the MiniApp example for what problems this addresses.

Link to “Intent to Implement” blink-dev discussion

Goals for experimentation
-Determine if this is useful in a real world app
-Currently we limit the scrollers developers can set to be exactly 100% viewport filling, do developers have other use cases?
-Should we still allow scrolling in the <body> element?
-Should we replace window.scrollY, window.scrollTo, etc. to target the new root scroller? document.scrollingElement? Would this be useful?
-Subjectively, does this make developing a multi-view app significantly easier.

Experimental timeline
I'd like to run this for two milestones, starting in M57:

57 Stable Ships ~Mar 14th, 2017
58 Stable Ships ~Apr 25th, 2017

And disable it at M59 branch from ToT:

59 branches from ToT ~Apr 13th, 2017

Any risks when the experiment finishes?
Minor usability regression, scrolling on the root scroller will no longer scroll the URL bar. But this is no worse than what exists today on many pages.

Ongoing technical constraints
None

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
The feature, as in the property on `document`, is available on all platforms. However, it's basically a no-op on desktops. The effects are currently only visible on Android.

OWP launch tracking bug
No OWP yet but implementation tracked in http://crbug.com/505516

Link to entry on the feature dashboard

Jeremy Roman

unread,
Jan 6, 2017, 3:42:32 PM1/6/17
to David Bokan, blink-dev, Dima Voytenko
Does document.scrollingElement respond to assignment to document.rootScroller? These two sound like they're conceptually the same thing, and I'm not sure I understand from the explainer what the semantic difference is.

David Bokan

unread,
Jan 6, 2017, 3:51:14 PM1/6/17
to Jeremy Roman, blink-dev, Dima Voytenko
It doesn't currently, it's one of the things I'd like to get feedback on. scrollingElement is used to determine which element controls and reflects viewport scrolling (window.scrollTo, scrollX, etc). This is semantically very similar to what rootScroller is trying to accomplish but, unless there's a good use case, it would add a lot of headache tying this with all the legacy cruft scrollingElement has to deal with.

Rick Byers

unread,
Jan 6, 2017, 3:59:44 PM1/6/17
to David Bokan, Jeremy Roman, blink-dev, Dima Voytenko
I'm probably too biased on this one to approve it myself (since only a single API Owner LGTM is required for experiments).  But I wanted to say that I'm really excited to get some real-world usage of this to help inform the impending spec debate so that we can fully ship a good solution ASAP.

Dima did a great job convincing us (based on his experience in Tau and Amp), this is a huge issue in building high quality mobile web apps (the workarounds cause all sorts of headaches).  No other mobile UI framework forces the root view to be special in this way (or even makes it scrollable by default AFAIK).  David's API effectively let's developers opt-in to a more native-like model where the root can be a simple container with multiple different scrollable views as children.  The AMP team has already tested the feature manually and is anxious to see some usage in the wild to help validate the design in practice.

Rick

Dimitri Glazkov

unread,
Jan 6, 2017, 4:05:10 PM1/6/17
to David Bokan, blink-dev, Dima Voytenko
LGTM1.

Dima Voytenko

unread,
Jan 9, 2017, 4:50:02 PM1/9/17
to Dimitri Glazkov, David Bokan, blink-dev
Amen.

Chris Harrelson

unread,
Jan 9, 2017, 6:48:06 PM1/9/17
to Dima Voytenko, Dimitri Glazkov, David Bokan, blink-dev
LGTM2

Amen.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Kenneth Russell

unread,
Jan 9, 2017, 6:56:54 PM1/9/17
to David Bokan, blink-dev, Dima Voytenko
On Fri, Jan 6, 2017 at 12:35 PM, David Bokan <bo...@chromium.org> wrote:
Contact emails

Spec

Summary
The document element (body in Chrome) has some special powers that other scrollers do not. For e.g. only scrolling in the <body> element hides the URL bar and shows overscroll glow.

document.rootScroller allows an author to give these powers to an arbitrary scroller, allowing iframes and divs to control the URL bar. This makes composing multi view apps significantly easier. See the MiniApp example for what problems this addresses.

Link to “Intent to Implement” blink-dev discussion

Goals for experimentation
-Determine if this is useful in a real world app
-Currently we limit the scrollers developers can set to be exactly 100% viewport filling, do developers have other use cases?
-Should we still allow scrolling in the <body> element?
-Should we replace window.scrollY, window.scrollTo, etc. to target the new root scroller? document.scrollingElement? Would this be useful?
-Subjectively, does this make developing a multi-view app significantly easier.

Experimental timeline
I'd like to run this for two milestones, starting in M57:

57 Stable Ships ~Mar 14th, 2017
58 Stable Ships ~Apr 25th, 2017

And disable it at M59 branch from ToT:

59 branches from ToT ~Apr 13th, 2017

Any risks when the experiment finishes?
Minor usability regression, scrolling on the root scroller will no longer scroll the URL bar. But this is no worse than what exists today on many pages.

Does this mean that the URL bar will never be hidden in Chrome on Android? If so, this sounds to me like a serious usability regression. The awful, sticky menu bars in use by many mobile web sites already significantly impact screen real estate; the New York Times is a concrete example. If the URL bar also weren't hidden, reading news in Chrome on Android would be a painful process.

-Ken

Alexandre Elias

unread,
Jan 9, 2017, 7:58:36 PM1/9/17
to Kenneth Russell, David Bokan, blink-dev, Dima Voytenko
On Mon, Jan 9, 2017 at 3:56 PM, Kenneth Russell <k...@chromium.org> wrote:
Any risks when the experiment finishes?
Minor usability regression, scrolling on the root scroller will no longer scroll the URL bar. But this is no worse than what exists today on many pages.

Does this mean that the URL bar will never be hidden in Chrome on Android? If so, this sounds to me like a serious usability regression. The awful, sticky menu bars in use by many mobile web sites already significantly impact screen real estate; the New York Times is a concrete example. If the URL bar also weren't hidden, reading news in Chrome on Android would be a painful process.

It just means a return to the status quo we're already shipping today.  "the root scroller" in that sentence refers to a scrollable subelement specially labeled as "root scroller" using this new API.  For the majority of pages that use normal root-document-element scrolling (such as the New York Times), they'll continue to hide the URL-bar irrespective of the status of this experiment. 

Kenneth Russell

unread,
Jan 9, 2017, 8:06:10 PM1/9/17
to Alexandre Elias, David Bokan, blink-dev, Dima Voytenko
On Mon, Jan 9, 2017 at 4:58 PM, Alexandre Elias <ael...@chromium.org> wrote:
On Mon, Jan 9, 2017 at 3:56 PM, Kenneth Russell <k...@chromium.org> wrote:
Any risks when the experiment finishes?
Minor usability regression, scrolling on the root scroller will no longer scroll the URL bar. But this is no worse than what exists today on many pages.

Does this mean that the URL bar will never be hidden in Chrome on Android? If so, this sounds to me like a serious usability regression. The awful, sticky menu bars in use by many mobile web sites already significantly impact screen real estate; the New York Times is a concrete example. If the URL bar also weren't hidden, reading news in Chrome on Android would be a painful process.

It just means a return to the status quo we're already shipping today.  "the root scroller" in that sentence refers to a scrollable subelement specially labeled as "root scroller" using this new API.  For the majority of pages that use normal root-document-element scrolling (such as the New York Times), they'll continue to hide the URL-bar irrespective of the status of this experiment. 

Thanks for this clarification Alex. Sounds good.

-Ken

Dima Voytenko

unread,
Jan 9, 2017, 8:13:48 PM1/9/17
to Kenneth Russell, Alexandre Elias, David Bokan, blink-dev
Further, this experiment expands the desired behavior to other web apps and frameworks that do not (or cannot) implement everything in the default scrollingElement and instead use scrollable divs to implement independent views in their apps. E.g. see https://photos.google.com. 

David Bokan

unread,
Jan 25, 2017, 2:51:07 PM1/25/17
to Dima Voytenko, Kenneth Russell, Alexandre Elias, blink-dev
FYI, I'm going to push this back to 58 while I resolve some issues around how rootScroller should interact with paint and hit testing with the paint-team.
Reply all
Reply to author
Forward
0 new messages