bi-07 step 03 — The real invalidation machinery

Goal

Map your implementation onto Blink's, and find the exact condition under which the engine gives up on precision.

Tasks

  1. Read core/css/style-invalidation.md in full — it is short and authoritative.
  2. Locate RuleFeatureSet, PendingInvalidationsMap, SelectorChecker::MatchSelector, and Element::StyleForLayoutObject. Map each to the part of your engine that corresponds.
  3. Find the fallback. Locate the code path that decides to invalidate a whole subtree. Write the condition in one English sentence. This is the most practically valuable thing in the module.
  4. Construct the pathology. Build two DOM changes with identical visual effect but ~100× different recalc scope. Confirm with DevTools' recalculated-element count.
  5. Style sharing. Add a unique inline style to every row of a 10,000-row list. Measure memory and recalc against the shared version. Explain the cliff.
  6. The cycle. Construct a container-query case where an element's style depends on a container whose size depends on that element. Predict, then check what browsers do, then find the rule that makes the cycle impossible.

Done when

  • Subtree-fallback condition written in one sentence
  • Two visually-identical changes with wildly different scope demonstrated
  • Style-sharing cliff measured
  • Complexity notebook entry on invalidation sets