Verification — bi-04-dom-internals

A module is complete when these pass against measured or observed output, not when the prose has been read.

  • mini-browser M3: DOM with correct appendChild ordering and hierarchy checks
  • Dirty-marking implemented twice (naive vs scoped); ops/sec table for a 10k-node tree
  • Forced-synchronous-layout loop measured, then batched; complexity class named
  • Detached-subtree leak built and found via retainer chain in a heap snapshot
  • Trace() method read; what an Element keeps alive written down

Gate (§44) — for every source-reading exercise in this module

  • Why does this code exist?
  • What invariant does it maintain?
  • Who calls it?
  • What does it call?
  • Which process and thread executes it?
  • What happens if it is removed?
  • How is it tested?
  • What simpler design would fail, and why?

Record