Missing substrate and sequencing — 2026-08-27
The logical document-tree substrate is now specified in #41. This issue is a future consumer of that contract, not an instruction to invent a physical DOM or start implementation. Follow isomorphisms/idric-arm-thumb#31; the first native selector-derived fixture uses already-decoded finite tag/class predicates over the bounded #41 tree. Raw CSS parsing, dynamic mutation, and invalidation are later stages.
Goal
Use CSS selector matching as another real IB workload for the compiler/backend branch experiments.
Selectors are a good browser-native control-flow family because they combine node tests, finite predicate dispatch, tree traversal, loops, nested conditions, and early exits. The point is not to force CSS into jump tables; it is to preserve an executable browser oracle and then see which machine control-flow form is actually appropriate.
First static matching ladder
Build a small deterministic DOM/tree fixture and exact oracle for:
div — tag match;.foo / #bar — class/ID match;[x=y] — attribute lookup and comparison;A > B — child relationship;A B — descendant traversal;A + B / A ~ B — sibling traversal;:is(A, B, C) — finite alternation;:not(...) — negated predicate;:has(...) — nested traversal with existential early exit.
Use nav:has(a.active) as a compact representative end target once the smaller cases work.
The oracle should establish exact matched node identities/order for the fixture so alternative implementations can be compared byte-for-byte or structurally without depending on a particular backend strategy.
Keep matching separate from invalidation
:has() also creates an important DOM-mutation problem: a descendant change can require reconsidering one or more ancestors. Track that explicitly, but do not make dynamic invalidation a prerequisite for the first static matcher benchmark.
A later invalidation fixture can ask:
- which mutations can affect a
:has() result;
- which ancestors must be reconsidered;
- how far propagation must go;
- whether dependency metadata can avoid rescanning unrelated subtrees.
Evidence rule
For any optimized implementation, retain:
- the portable IB semantic oracle;
- exact fixture tree and selector set;
- match results/order;
- nodes visited / comparisons where measurable;
- emitted code when a native backend owns the implementation;
- code size and target timing separately;
- competent baseline behavior, including non-wins.
Related
Missing substrate and sequencing — 2026-08-27
The logical document-tree substrate is now specified in #41. This issue is a future consumer of that contract, not an instruction to invent a physical DOM or start implementation. Follow isomorphisms/idric-arm-thumb#31; the first native selector-derived fixture uses already-decoded finite tag/class predicates over the bounded #41 tree. Raw CSS parsing, dynamic mutation, and invalidation are later stages.
Goal
Use CSS selector matching as another real IB workload for the compiler/backend branch experiments.
Selectors are a good browser-native control-flow family because they combine node tests, finite predicate dispatch, tree traversal, loops, nested conditions, and early exits. The point is not to force CSS into jump tables; it is to preserve an executable browser oracle and then see which machine control-flow form is actually appropriate.
First static matching ladder
Build a small deterministic DOM/tree fixture and exact oracle for:
div— tag match;.foo/#bar— class/ID match;[x=y]— attribute lookup and comparison;A > B— child relationship;A B— descendant traversal;A + B/A ~ B— sibling traversal;:is(A, B, C)— finite alternation;:not(...)— negated predicate;:has(...)— nested traversal with existential early exit.Use
nav:has(a.active)as a compact representative end target once the smaller cases work.The oracle should establish exact matched node identities/order for the fixture so alternative implementations can be compared byte-for-byte or structurally without depending on a particular backend strategy.
Keep matching separate from invalidation
:has()also creates an important DOM-mutation problem: a descendant change can require reconsidering one or more ancestors. Track that explicitly, but do not make dynamic invalidation a prerequisite for the first static matcher benchmark.A later invalidation fixture can ask:
:has()result;Evidence rule
For any optimized implementation, retain:
Related