Proposal: Exposing native scroll as API
kaizhu256 at gmail.com
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 @
https://konvajs.org/docs/sandbox/Canvas_Scrolling.html. 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.
will scroll to element in www.example.com containing text "You may use this
 Scroll-To-Text using a URL fragment
On Fri, Jun 21, 2019 at 10:33 AM Adam Eisenreich <akxe at seznam.cz> 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 mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss