Infinite Pixels

But it's specifically 25bits not 24?

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.

The correct answer. In particular, up to 2 ^ 24 the float32 behaves like a regular integer, which can be important in some cases. Above that value, the integer starts to have missing values, and strange int behavior such as (n+1)+1 not equal to (n+2)

You’re confusing the JavaScript keyword Infinity, which has been around forever, with the CSS keyword infinity, which has only been around for 2–3 years <https://caniuse.com/mdn-css_types_calc-keyword_infinity>.

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.

[dead]

According to the spec:

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.

Final boss of z-index

Selling pixels at a dollar each to make an Infinity Dollar Website™.

We use it in Tailwind CSS v4 for pill-shaped borders:

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

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

It was also a fun time to interview. Can you write a CSS snippet that will make a box red in IE5, Blue in IE6+, and is Yellow in Firefox but black in Netscape? CSS these days is no longer an adventure — they just tend to work.

I always grab the CSS reset Also the purple story

Totally refreshing to me. Imagine -- a techie who doesn't take himself too seriously!

"skullmeats" definitely made me wince.

Firefox’s limit is 17,895,697 pixels. Others have a limit less than twice as high, so given you’re aiming for a value way higher than that, it’s not a browser-specific issue, except insofar as Firefox ignores rather than clamping, so you have to detect Firefox and clamp it manually.

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.

Is it completely client side? Why does it have a 2 billion row limit? Where are the limitations coming from?

Do you even need to have one scroll pixel == one screen pixel (or even one scroll pixel == one spreadsheet row)? At the point of 2 billion rows, the scrollbar really falls apart and just jumping to an approximation of the correct location in the document is all anyone can hope for.