Verification Checkpoints

Checkpoint 1 — content-visibility collapses initial layout

npm run containment

Pass: content-visibility: auto reduces initial layout by ≥ 80% versus no containment, with an identical DOM node count in all three rows.

Fail — no improvement: the cards are all within the viewport (raise CARDS), or contain-intrinsic-size is missing so every card is measured anyway.

Checkpoint 2 — contain: strict does not fix initial render

Pass: contain: strict is within ~10% of the no-containment row for initial layout.

This checkpoint passes when the number is unimpressive. That is the point: containment bounds propagation, it does not skip rendering. Conflating the two is the most common containment mistake, and the measurement is what prevents it.

Checkpoint 3 — Containment pays on the update path

npm run invalidation

Pass: contain: strict + fixed height reduces layout time by ≥ 50% versus none, with identical layout counts across all three variants (120 here).

Fail — layout counts differ: the forced synchronous layout is missing, so the browser coalesced differently per variant. The comparison is invalid until counts match.

Also note the increase in style recalc under strict (0.5 → 1.5 ms). Containment has bookkeeping cost. You should be able to say when that cost would exceed the benefit.

Checkpoint 4 — Layer order beats specificity, and !important inverts it

npm run cascade

Pass: all four cases resolve as predicted — in particular case 2 (0,1,0 in a later layer beats 1,1,0 in an earlier one) and case 4 (!important in the earlier layer wins).

Case 4 is the checkpoint that matters. State the consequence: a design system shipping defaults with !important becomes unoverridable by every consuming application.

Checkpoint 5 — You can pick the right tool from a symptom

Not a script. For each symptom, name the tool and say why the other one would not help:

SymptomYour answer
50,000-row report takes 3 s to first paint
Expanding one accordion row janks the whole page
A third-party widget's styles override ours
z-index: 9999 stopped working after a perf change
Theme switch causes a visible full-page flash

Pass: five correct tools with a reason. Row 4 requires recognising that contain: paint creates a stacking context — a performance change causing a z-index bug.

Module completion

  • Checkpoints 1–5
  • steps/04-principal-review.md answered
  • content-visibility applied to one real long list you own, with before/after numbers — or a documented reason it does not apply
  • A layer stack drafted for one real codebase, including where unmigrated legacy CSS sits