Proposal: Exposing native scroll as API

kai zhu kaizhu256 at
Sat Jun 22 18:41:29 UTC 2019

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

On Fri, Jun 21, 2019 at 10:33 AM Adam Eisenreich <akxe at> wrote:

> 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>`:
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list