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.
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.
IE4 did the opposite and assumed everything was sized zero and filled sizes as they become known. this allowed them to load objects and render them as the page objects load appearing to be substantially faster at loading than Netscape.
Early engineering decisions like this can make or break a company. Not saying this was the only challenge Netscape had, but it was one that really drove the need to build the Gecko layout engine. Despite some wildly misleading yet famous blogs written by a Microsoft engineer discussing what happened internally at Netscape that he couldn’t possibly know about and basically got totally upside down and self serving ……
Typo, the last browser in this sentence should be "Chrome", right?
But this does fall apart for very very large grids, as you get close to the height limit described in this article.
For a project that I'm working on, I ended up re-implementing scrollbars, but it's super janky - and even more so on mobile where you lose the "flick"/inertia/momentum touch gestures (or you have to re-implement them at your peril).
Are there any good tricks/libraries to tackle this? Thanks!
[0] https://news.ycombinator.com/item?id=44825028
If that doesn't help, maybe check out this fun post (no native scrolling experience):
it's not crazy to stack virtual lists... at that point, I might also just see that the user is near/at the end of the list, and just swap out the content completely and place them back at scrolling position y:0 or something
for sure, I shouldn't make perfect the enemy of good here. thanks for the ideas!
Sounds equally fun! Just like the uuid one, also seems very worth bookmarking for a fitting moment
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.
Now SVG… try defining a view box up where float precision drops, and interesting things happen.
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.
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.
.rounded-full {
border-radius: calc(1px * infinity);
}
.rounded-full {
border-radius: 9999px;
}
if there was a period of time where 24-bit values were in vogue, I must have missed it.
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.
> 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.
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.