fw-10 — Broader Ideas

The clearest case of internals determining architecture

You cannot design a good virtualizer without knowing DOM cost (bi-04), layout cost and forced synchronous layout (bi-08), paint and property trees (bi-09), and compositor scrolling (bi-10).

It is the module that proves the browser track was worth doing, because every decision — transform versus top, ResizeObserver versus getBoundingClientRect, overscan size — is decided by a fact from another module.

Check whether the platform already did it

content-visibility: auto with contain-intrinsic-size keeps every row in the DOM while skipping their layout and paint. At a couple of thousand rows it frequently beats a virtualizer and keeps find-in-page, accessibility, anchor links, and print working.

The general habit: before building a mechanism, check whether the platform has shipped a declarative version. The platform's version is usually worse at the extreme and much better at everything surrounding it.

Pricing the right-hand column

Virtualization trades platform behaviours you got for free — find-in-page, screen-reader navigation, tab order, selection, print, scroll restoration — for render performance. Several have no reliable mitigation.

An engineer who reaches for it by default has priced only the left column. Stating the trade explicitly in a design review is a small act that materially improves decisions.

aria-setsize is the pattern again

Telling assistive technology "item 4,207 of 100,000" when only 20 exist is an author-supplied promise substituting for information the runtime cannot observe — the fifth instance in this curriculum.

Next

fw-12 builds the accessibility queries that make the mitigation testable rather than aspirational.