bi-03 — Broader Ideas
Error recovery as a design decision
HTML specifies what happens for invalid input, and that decision — not any feature — is the largest interop win in the platform's history. XHTML tried the alternative and lost.
The generalisation: when many independent implementations must agree, specifying failure is more valuable than specifying success. Apply it to your own formats, protocols, and config files. If two implementations of your schema disagree about a malformed document, you have shipped a compatibility problem you will pay for later.
Speculation, everywhere
"May be wrong, may never be observable" is a reusable technique for making blocking work faster without changing semantics:
| System | Speculative pass | Permitted to be wrong about |
|---|---|---|
| HTML parser | preload / background scanners | which resources are needed |
| Compositor | scroll before the main thread answers | whether JS wanted preventDefault |
| CPU | branch prediction | the branch |
| Databases | prefetch, read-ahead | which pages are needed |
| Your app | prefetch on hover, speculative render | what the user will do |
The discipline is identical: the speculative path must not mutate state anything else can observe.
Mutation XSS is a parser problem
The gap between a sanitiser's parse and the browser's parse is the vulnerability. This is why
parser-aware sanitisation and Trusted Types are the only sound approaches, and why "we strip
<script> with a regex" is not defence in depth — it is a second, disagreeing parser.
If your product accepts HTML from users, this module is directly load-bearing on your threat model.
Next
- mini-browser M2–M3 turns this into code.
bi-04picks up where the parser hands off: what happens to a node after it is created.fw-06reuses the tokenizer skill for template compilation — you will write a state machine over markup a second time and it will be much faster.