Proposal: Exposing native scroll as API

# Adam Eisenreich (a year ago)

Hello everyone. I think browsers should expose the native scroll as API.

Possible uses:

  • Native-like scroll in canvas apps (games) - Google's Proxx ( had to do quite a bit of magic to have native scroll for a game.
  • Camera controls for touch device (3D model preview) Gesture recognition (maybe)
  • Infinite scroll (they could get rid of the invisible long div, that makes the scrolling inside possible) - Angular virtual scroll implementation
# guest271314 (a year ago)

What is meant by "native scroll"?

  left: leftValue, // e.g., element.getBoundingClientRect().left
  top: topValue, //  element.getBoundingClientRect().top
  behavior: "smooth"


# Adam Eisenreich (a year ago)

I mean, that there should be an API that would say, how an element would scroll, if it was in place of for example a <canvas>.

const scrollArea = new ScrollArea(canvasElement, {
  borderBox: 'unlimited', // Default would be the element
  //viewPort: '100#200'

scrollArea.addEventLisener('scrollStart', event => {
  // Possibly others
scrollArea.addEventLisener('scroll', () => {});

scrollArea.addEventLisener('scrollEnd', () => {});


function step(timestamp) {
  canvas.translate(, scrollArea.currentOffset.left);

# guest271314 (a year ago)

Not following what

if it was in place of

is intended to mean?

It is currently possibble to scroll to any portion of the viewport and get the current position of any element during scroll event.

What is being proposed that is not already possible?

# Adam Eisenreich (a year ago)

If you want to have native scrolling experience for <canvas> you need to either implement your own scrolling behaviour, or you will create <canvas> of size much bigger than screen, that way it overflows screen and shows scollbars, but then you must only render on part of canvas as most is hidden.

I would like an API I would ask: If this element would be scrollable, when scrolling would actually occur? How long would the animation take on this platform? Where the end offset would be? Scrolling isn't same for each platform ex.: PC, Mac, iOS, Android.

There is video about proxx, it mentions other problems too, but they explain there how they did implement natural scrolling for <canvas>:

# Claude Pache (a year ago)

Le 21 juin 2019 à 16:07, Adam Eisenreich <akxe at> a écrit :

Hello everyone. I think browsers should expose the native scroll as API.

Possible uses:

Scrolling is not part of ECMASCript (the core language), but is provided by a Web API. This is out of the scope of this mailing list.

# guest271314 (a year ago)

What are you NOT able to output right now relevant to programmatically scrolling using existing DOM methods, Web Animations API, and/or CSS? Have you filed an issue at browsers, WHATWG HTML, and WHATWG DOM?

# kai zhu (a year ago)

the referenced video was entertaining to watch (and i learned new things about typescript and proxies), but i still don't understand your UX-problem -- at least enough to know what/how a new standard-api would help.

there's a bunch of canvas-scrolling examples @ examples #1 and #4 implement native canvas-scrolling, with the latter having less jankiness on my mobile-chrome. maybe you're asking for consistent #4 css-behavior across all mobile-browsers (i have no idea if it works as well in ios-safari)? that would be w3c csswg's domain.

also somewhat-related -- chrome is debating an intent-to-implement feature for scrollTo-behavior for text-fragments. for example: will scroll to element in containing text "You may use this domain". [1]

[1] Scroll-To-Text using a URL fragment bokand/ScrollToTextFragment

# Andy Earnshaw (a year ago)

As Claude pointed out, Scrolling is not part of ECMAScript. On the subject of improved support for virtual scrolling, I've started discussions on CSS-WG and Web Components issue trackers.

w3c/csswg-drafts#3397, w3c/webcomponents#791

Please feel free to add your +1 there or contribute your own use cases to the discussion.