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, a less-surprising number.
Firefox's units are quite smart, actually. 60 is divisible by 3, 4, 5 and 6, so they are quite future-proof for the future when we'll have the displays with devicePixelRatio = 6.
One of the factors for choosing 60 was its nice divisors, perfectly handling these scaling factors (and also, I rather suspect, though it wasn’t pointed out, 1.25×, 1.5×, and 2.5×). https://wiki.mozilla.org/Mozilla2:Units#Proposal describes the reasons, including others. It’s a nice piece of history to read.
But we’re unlikely to get mainstream devices beyond 3×.
CSS’s reference pixel has a visual angle of about 77″ <https://www.w3.org/TR/css-values-3/#reference-pixel>. Human eyes cap out at 28″ <https://www.swift.ac.uk/about/files/vision.pdf#page=2>. This means 2.75× is the absolute limit of human resolution at a device’s nominal viewing distance, and you have to come in closer for it to even be possible to resolve a single device pixel. 6× means “you can’t even detect a single pixel until you halve the distance between eye and surface”.
Are there contexts in which this could make sense? Definitely: an art display that’s intended to be viewed at a distance of 10 metres, but you can also get up close to see details—it’d be nice if you can barely make out the pixels at 1 metre.
But mainstream devices? I don’t think anyone’s gone beyond 3×, and I don’t think they will. 3× is at the transition from “diminishing returns” to “no further returns are even possible, going further makes things strictly worse” (increasing monetary, power, memory and processing costs).
As it stands, even the benefits of choosing 60 have turned out pretty slim; the battleground and constraints have shifted so that divisibility isn’t as important as I think it was expected to be. And it has costs, too; there’s a reason WebKit shifted to 64 after a bit, even though it doesn’t even do 1.5× perfectly, which was probably the most common factor other than 1× at the time, and is possibly even more common now.
In engineering, they used to use the foot ' inch '' line ''' and point '''' where each unit was 1/12th the size of the previous one. The european typographic point used to be 1/144th of an inch. Watch components are measured in points.
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, a less-surprising number.
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, all you needed was 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.