bokand/root-scroller

document.rootScroller API proposal

root-scroller's Issues

Describe why the root view "specialness" aren't just browser bugs

The main objection I imagine to this proposal is: "All the reasons you list for how the root scroller is special are just browser bugs - rather than introduce a new API and hoist the problem on developers, browsers should just fix those bugs".

IIRC you had some compelling arguments against this, but I don't see them in the explainer. Eg. there's an accessibility argument around not wanting to depend on heuristics to identify the primary scroller when an accessibility tool (or just the spacebar) is used to "scroll the page".

I think there was also a predictability argument: helping developers reason about exactly when scrolling a given div will hide the top controls. eg. it's better to have an API that can fail with a specific exception for why a div can't be a root scroller, then to silently change behavior when there's a subtle issue like a single-pixel gap or occlusion etc.

Allow fixed header

From https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/COF0YKkjZVQ:

Currently we limit the scrollers developers can set to be exactly 100% viewport filling, do developers have other use cases?

Imagine a grid/flexbox layout like this which fills 100% of the viewport:

+--------------+
|    HEADER    |
|--------------|
|              |
|              |
|   SCROLLER   |
|              |
|              |
|--------------|
|    FOOTER    |
+--------------+

This is a common native app structure. Developers often use position: fixed for the header instead of grid/flexbox to address the problems this project aims to solve. As a result the scrollbar is rendered over the top of the header, and the developer has to use hacks to ensure the content has a top-padding matching the height of the header (although position: sticky helps here).

Ideally the developer should be able to transition from one scrollable div to another while the header and footer remain static.

Unfortunately the 100% viewport requirement gets in the way here.

rootScroller shouldn't be a readonly property

This API shouldn't use a readonly property and introduce a setRootScroller method, it should instead have a writable property.

Implicit root scroller was unexpected

On https://proxx.app, the URL-hiding behaviour was unwanted during games because the viewport height only changes once the URL bar is fully hidden/shown. This causes anything fixed to the bottom of the viewport to snap around in a really ugly way.

Sometimes this is acceptable for content sites, but in the game, scrolling up & down would happen frequently, and the viewport size changing became disruptive, or worse, resulted in controls being outside the visible viewport.

We tried to fix it by creating a different element for the scrolling, but since it was full size, we ran into implicit root scrolling. In the end, we worked around it by making the scrolling element 1px less than full size.

It feels like there should be a less hacky way around this. Maybe a way to prevent the URL bar hiding regardless of which element is scrolling?