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.
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.
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.
> 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.
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.
As noted by another comment here [0], when you use a virtual DOM/canvas based "infinite" data grid such as Glide Data Grid [1] or TanStack Virtual [2], you get the performance/usability of native scrollbars because under the hood, both of those libraries create scrollable DIVs with a very large height. ie, you're scrolling a big empty div, and a viewport into the "infinite" grid is actually drawn in the canvas.
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!
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...
So only slightly related Netscape used to assume the layout during load was infinite and would resolve features to their size as the sizes are known, which meant usually nothing showed until everything was loaded in a world of div and tables.
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 ……
19 comments
[ 4.0 ms ] story [ 35.8 ms ] threadSince 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
> 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, 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.
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
[1] https://github.com/glideapps/glide-data-grid
[2] https://tanstack.com/virtual/latest
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...
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 ……