CHchrismorgan·Dec 14, 2019
Probably the most common use case for such things is progressively-rendered/-loaded lists, where you know the number of items and the height of each item in the list, so that you can reserve all the space and provide a meaningful scrollbar, and have a limited number of children absolutely positioned on screen at any given time.
This gives a far better experience than infinite scrolling (which has no meaningful scrollbar, so you can’t jump to the end or an arbitrary point in the middle) or pagination (which is just generally painful once you want something not at the start).
We do this in Fastmail’s webmail, and have put in workarounds for overly-tall elements breaking browsers. https://github.com/fastmail/overture/blob/41cdf36f3e7c8f0dd1... lists them, including some values at which things break. (Actually, IE doesn’t allow containers any
Read the rest
where near that tall, capping effective values much earlier, with the consequence that you can’t access things near the end of the list. But the problem was that once you get much larger still, it starts ignoring the values you specify altogether, which would break the entire technique.)
For us, the most common height of each email’s entry in the list is 51px; at that, 400,000 emails is enough to get to 20,400,000px high, which is enough to break both IE and Firefox (not sure about Chrome or Safari, I’ve never actually tested it; their failure mode may well just be different, limiting numbers instead of ignoring them).
400,000 emails in a mailbox isn’t all that common, but it does happen.