Infinite Pixels

If that doesn't help, maybe check out this fun post (no native scrolling experience):

https://everyuuid.com

https://eieio.games/blog/writing-down-every-uuid/

This was solved by a now unmaintained virtualization library that predates both of these libraries: https://github.com/bvaughn/react-virtualized

The react-virtualized library works around this issue by scaling the the scroll position it sets for a row based on the ratio of "max CSS height allowed by browser" to "computed height of all rows" if the latter is greater than the former: https://github.com/bvaughn/react-virtualized/blob/master/sou...

In Fastmail’s case (see my top-level comment), making the end of a ridiculously large mailbox inaccessible was considered acceptable. In a spreadsheet, that’s probably not so, so you need to do something different. But frankly I think you needed to use a custom scrollbar anyway, as a linear scrollbar will be useless for almost all documents for anything except returning to the top.

Rendering the content, however, to a canvas is not particularly necessary: make a 4 million pixel square area, hide its scrollbars, render the outermost million pixels of all edges at their edge, and where you’re anywhere in the middle (e.g. 1.7 billion rows in), render starting at 2 million pixels, and if the user scrolls a million pixels in any direction, recentre (potentially disrupting scrolling inertia, but that’s about it). That’s basically perfect, allowing native rendering and scrolling interaction, meaning better behaviour and lower latency.

btw "toot" is the de-facto standard jargon for "post" on Mastodon-based social media, so that sentence isn't actually an example of this silliness.

And actually I’d be quite surprised if the infinity keyword is even relevant here; I would expect the same results if you changed each calc(infinity * 1px) to 9999999999999999px. Firefox (and, if you go far enough back, IE) will still ignore overly large height declarations, and WebKit-heritage browsers will clamp it.

As in n+1 == n once you go past 2^24 on a float and here they are at 2^25-1. So it doesn't quite make sense as a reason to me.

There's a post above that browsers divide pixels into 1/64th of a unit which accounts for 6bits which puts this limit at precisely that of a signed 32bit integer. This makes much much more sense than the significand of a float.

Now SVG… try defining a view box up where float precision drops, and interesting things happen.

  .rounded-full {
    border-radius: calc(1px * infinity);
  }

  .rounded-full {
    border-radius: 9999px;
  }

These constants are defined mostly to make serialization of infinite/NaN values simpler and more obvious, but can be used to indicate a "largest possible value", since an infinite value gets clamped to the allowed range. It’s rare for this to be reasonable, but when it is, using infinity is clearer in its intent than just putting an enormous number in one’s stylesheet.