bi-07 — Broader Ideas
Invalidation is the general problem
RuleFeatureSet inverts the stylesheet: instead of "selector → matching elements," it precomputes
"feature → what to invalidate." That is the same structure as:
| System | Index | Invalidated by |
|---|---|---|
| Blink style | RuleFeatureSet | a class/id/attribute change |
Reactive runtime (fw-03) | dependency sets | a signal write |
Build system (fw-07) | dependency graph | a file change |
Query cache (fw-09) | key → subscribers | a mutation |
| Database | secondary index | a row write |
| CDN | cache tags | a purge |
Every one has the same failure modes: invalidate too little and you serve stale results; invalidate too much and you have no cache. And every one has a fallback for when precise analysis is impossible — Blink's whole-subtree invalidation is a cache purge.
Having built one, you can evaluate all of them.
Author-supplied guarantees, again
contain and content-visibility are the author telling the engine "nothing inside affects
anything outside," which unlocks skipping work the engine could not otherwise skip. Container
queries then require containment, because the restriction is what makes the feature implementable
at all.
That is a design lesson worth stating: when a feature risks circularity, add a restriction that makes the cycle impossible rather than a limit that makes it terminate. Restrictions keep systems analysable.
Take this to your design system
Utility classes vs CSS-in-JS vs inline styles is usually argued on ergonomics. This module gives you the mechanical arguments: match cost, invalidation scope, and style sharing, which inline styles defeat. On a 10,000-row table that is a memory and recalc cliff, not a slope.
Next
bi-08 is what style feeds; bi-09 shows which property changes avoid it entirely. fw-03 builds
the same invalidation idea in 200 lines of JavaScript, which is the cheapest way to understand it.