Firefox simply ignores height declarations that resolve to a value greater than exactly 17895697px. What’s this value? Just a smidgeon under 2³⁰ sixtieths of a pixel, which is Firefox’s layout unit. (It’s the last integer before 2³⁰ sixtieths, which is 17,895,697.06̅ pixels, 4⁄60 more.) I presume Firefox is using a 32-bit signed integer, and reserving another bit for something else, maybe overflow control.
Five years ago, Firefox would ignore any CSS declarations resolving like that, but somewhere along the way it changed so that most things now clamp instead, matching WebKit-heritage behaviour. But height is not acting like that, to my surprise (I though it was).
WebKit-heritage browsers use a 1⁄64 pixel layout unit instead. Viewed in that light, the 2²⁵ − 1 pixels is actually 2³¹ − 1 layout units, more like what you’d expect.
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)
yosefk · 18m ago
But why are 32b floats relevant? JS, the language famously representing ints as floats, uses 64b floats. Who puts ints into 32b floats and cares about precision loss?
matthewmacleod · 5m ago
Layout engines are not implemented in Javascript.
maxloh · 1h ago
Blink, Chrome's rendering engine, was forked from WebKit (Safari) in 2013.
Since WebKit already supported the infinity value at the time of the fork [0], it's highly probable that they share the same underlying code. This would explain their similar behavior.
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.
maxloh · 42m ago
Thanks for the clarification. However, the number is likely encoded in binary format, which is why you're seeing 2²⁵ in the article.
calibas · 46m ago
What's the actual use case for "infinity" in CSS?
szatkus · 4m ago
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.
jdauriemma · 44m ago
Final boss of z-index
azangru · 8m ago
Isn't the final boss of z-index the top layer?
Rendello · 32m ago
What about `infinity + 1`? ;)
dole · 20m ago
z-index = i_love_you;
PaulDavisThe1st · 21m ago
Cantor has entered the chat.
adamwathan · 18m ago
We use it in Tailwind CSS v4 for pill-shaped borders:
...as opposed to what everyone has done historically, which is pick some arbitrary huge value like:
.rounded-full {
border-radius: 9999px;
}
No real practical benefit, just satisfyingly more "correct".
RoryH · 1h ago
This article triggered flashbacks to 20 years ago and using all sorts of crazy CSS to hack the browser to do what you needed it to. Nowadays CSS is (usually) a remarkable land of sanity in comparison.
ge96 · 16m ago
I always grab the CSS reset
Also the purple story
Brajeshwar · 58m ago
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.
breckognize · 50m ago
Kinda related - our product, rowzero.io, is a browser-based spreadsheet with a 2 billion row limit. We initially built the client as anyone would, using a div per cell. We tried to use an off-screen div to take advantage of the browser's native scrollbars but ran into document height limits. Firefox's was 6M pixels iirc. The solution was to do rendering in canvas and draw the scrollbars ourselves.
zwnow · 42m ago
Is it completely client side? Why does it have a 2 billion row limit? Where are the limitations coming from?
mmastrac · 47m ago
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.
echelon · 48m ago
> came across a toot
> For the sake of my aching skullmeats
> My skullmeats did not thank me for this
> I hear you asking.
> Maybe if I give my whimpering neurons a rest
> I’d be much happier if someone just explained it to me; bonus points if their name is Clarissa.
> my gray matter needs a rest and possibly a pressure washing
There is a software engineering equivalent of the "theater kids" meme, and this is it. There's an abundance of exuberance in this writing.
I'm glad we have such diversity in perspective. It's a nice change from the usual terseness, though I'm not sure I could read in this style for an extended period.
Five years ago, Firefox would ignore any CSS declarations resolving like that, but somewhere along the way it changed so that most things now clamp instead, matching WebKit-heritage behaviour. But height is not acting like that, to my surprise (I though it was).
WebKit-heritage browsers use a 1⁄64 pixel layout unit instead. Viewed in that light, the 2²⁵ − 1 pixels is actually 2³¹ − 1 layout units, more like what you’d expect.
IE had the same behaviour as Firefox used to, but with a much lower limit, 10,737,418.23 pixels (2³⁰ − 1 hundredth pixels), which was low enough to realistically cause problems for Fastmail if you had about 200,000 messages in a mailbox. I’ve written about that more a few times, https://news.ycombinator.com/item?id=42347382, https://news.ycombinator.com/item?id=34299569, https://news.ycombinator.com/item?id=32010160.
Typo, the last browser in this sentence should be "Chrome", right?
Since WebKit already supported the infinity value at the time of the fork [0], it's highly probable that they share the same underlying code. This would explain their similar behavior.
[0]: https://caniuse.com/?search=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.
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.
> For the sake of my aching skullmeats
> My skullmeats did not thank me for this
> I hear you asking.
> Maybe if I give my whimpering neurons a rest
> I’d be much happier if someone just explained it to me; bonus points if their name is Clarissa.
> my gray matter needs a rest and possibly a pressure washing
There is a software engineering equivalent of the "theater kids" meme, and this is it. There's an abundance of exuberance in this writing.
I'm glad we have such diversity in perspective. It's a nice change from the usual terseness, though I'm not sure I could read in this style for an extended period.