I expect good baseline performance from a combination of both the HTML and JavaScript code of the page, and the browser. Sure it's nice if the browser does some tricks to make a badly written page that has 2 GB of image data on it play somewhat more nicely on the system, but if that page loads badly its not the browsers fault, its the fault of the web developer who didn't paginate, or use Infinity.js or something like that.

The reason why I call the Firefox fix a workaround is because the proper way to solve the problem of 2 GB of image data on a page is by using a UITableView style wrapper.

But HTML 5 doesn't have such an element for us to make use of. The proper fix would be to add such an element to HTML itself, but obviously that's something that takes years to do and to get it adopted across all browsers.

So in the meantime tricks like what Firefox is doing are nice to help prevent inexperienced web developers who create abominably inefficient webpages from consuming too much system resources when an unfortunate victim downloads the page.

Honestly, this is pretty similar in effect to a UITableView-style wrapper, except that it's handled automatically by the platform. Sophisticated JS-only webapps are perhaps a different case, but a site that consists primarily of HTML and CSS should work just fine across a variety of different devices with different performance characteristics and memory capacities, automatically. This is one of the advantages of a declarative model like HTML/CSS: it gives the implementation a lot of freedom to apply optimizations and adapt to the limitations of the platform it's running on.

I guess what I'm trying to say is that this isn't a workaround - it's one of the primary reasons HTML and CSS are architected in the way that they are. This has nothing to do with helping inexperienced web developers and everything to do with preserving the declarative nature of basic web content.