Genera - a generated web engine #

Coverage #

Computed against browser-compat-data 8.0.4 (17259 leaf keys, 42 rules in docs/feature-map.json) on 2026-09-22.

See docs/dashboard.md for what these statuses mean and how this table is kept in sync.

Generate a web rendering engine from specs and tests.

Why #

Building a web engine by hand costs hundreds of engineers and many years. Only a few companies can pay that, so only a few decide how the web works. Genera aims to generate the engine instead: from the specifications, with WPT results and the three shipping engines (checked against each other) as the tests. Once the generation pipeline exists, each extra engine costs very little, and that changes who can have one.

Goals #

• Modular, fit for purpose. Web features are units that can be included or left out. An engine can be sized to what a device class or an application needs, from a full browser down to one app's engine with everything else stripped out.
• High performance across device classes. A smaller engine does less work: fewer features to check, less memory and less code on constrained hardware.
• Easy to embed. A small, self-contained engine with a clear API, for apps, devices and tools that today have to ship all of Chromium or go without.
• The fastest engine to update. When a spec or a test changes, the affected part is regenerated and re-verified, without a person reimplementing it by hand.

Together these aim to beat hand-built engines on cost, size and speed of change. Today a few companies own the engines and everyone else uses theirs; the long-term aim is that everyone gets an engine.

Status #

The three-engine verification harness is built and measured: layout results from three browsers are compared automatically, and the wpt.fyi vote table and script-observable trace votes serve as further tests. Conformance-suite oracles for canvas, WebGL, Web Audio and the WebGPU CTS have landed measurements too. Engine bootstrap steps 1 through 3 — DOM and style, box construction, and a fragment tree with explicit sizes — are hand-written in crates/dom and crates/layout and pass their oracles. Step 4's three block-layout algorithms — the width equation, margin collapsing and percentage resolution — have each been generated from CSS 2.1 prose through the loop and admitted against the three-engine vote, each behind a hand-written seam, and one non-geometry feature has been generated against a JS-state oracle. What that shows, and what would prove the thesis, is in roadmap.md → "Proof of concept"; the plan and the decisions behind it are in roadmap.md.

Findings so far #

• Three browsers agree on generated block layout, and a third engine identifies the outlier. Across 235 documents compared in Chromium, Firefox and WebKit, 699 of 705 engine-pair comparisons agreed within tolerance (measured at commit 3ca7323; the enumerated set has since grown by one case, so reproducing this exact count means checking out that commit). All six disagreements were the same twelve-deep percentage-nesting shape; a third engine let majority voting name Firefox as the outlier on every affected measurement, rather than only reporting an unresolvable disagreement between two. Detail: docs/firefox-app-units.md.
• The Firefox difference is a real web-compat problem. Gecko rounds lengths to 1/60 px where Blink and WebKit use 1/64 px. When a computed width such as a flex basis with gap, or a nested percentage, lands off the grid, the difference becomes visible: a flex item wraps only in Firefox, or offsetWidth differs by a whole pixel. Minimal reproductions match Mozilla-diagnosed site breakage (Slack, Google Store, Samsung) and Mozilla's open bug on changing the unit (bug 1719314). Detail and reproductions: docs/firefox-app-units.md, experiments/firefox-compat/.
• The WPT vote table agrees across most of the suite. Built from wpt.fyi's per-subtest results joined to browser-compat-data, a stable three-engine majority covers 2,162,676 of 2,282,301 distinct test/subtest keys (94.8%); 54,421 keys pass in exactly one stable engine with all three having run, and 17.1% of those are rescued by a different engine's experimental channel. Detail: docs/wpt-votes.md.
• Engine bootstrap steps 1 through 3 pass their oracles. DOM and style matched browsers on 3,791 of 3,791 comparable computed-style values; box tree construction matched box existence on 223 of 223 nodes; the first real geometry comparison, on fixed-size boxes with no auto values, passed all 3 of its test cases. Detail: roadmap.md → "Phase 1 — Engine bootstrap".
• Script-observable behavior agrees across engines too. Trace probes run under a fake-media launch profile agree on 15 of 18 engine pairs; the three disagreements are a real platform difference (which keys a fake camera's getSettings() reports), not a harness gap. Detail: docs/dump-format.md → "Trace protocol".
• Conformance suites are a usable oracle for most of canvas, WebGL and Web Audio. Measured across three engines, counting a test usable once at least two of three agree: WPT canvas 82.6% usable (92.7% excluding tentative tests), the Khronos WebGL suite including dEQP 99.7%, and WPT Web Audio 74.4% (85.6% excluding tentative; 92.7% for OfflineAudioContext tests). Detail: docs/conformance-oracles.md.
• The WebGPU CTS gives a usable oracle for most of validation, about half of numeric execution. The full CTS run under dawn.node on lavapipe, cross-checked against Chromium on SwiftShader, gives an estimated coverage of about 85% exact for validation and about 50% within ULP tolerance for numeric execution. Detail: docs/webgpu-cts.md.
• A content-scoped engine is designed, and its Stage 0 analyser has landed. Walking HTML and CSS with html5ever and cssparser and mapping to pinned browser-compat-data and web-features releases, it found mdn-docs touching 11.65% of html.* and 2.80% of css.* browser-compat-data keys on a five-page corpus, and danluu-blog 6.92% and 0.93%. Detail: docs/content-scoped-engine.md.
• A logic-programming layer earns its place narrowly, as an oracle for facts a geometry diff can't see on its own. Margin collapsing expressed as forward Datalog, checked against a live three-engine vote, agreed with the browsers on all 1195 of 1195 trustworthy offsets across 227 cases. On seeded mutants it caught bugs the geometry diff missed: the sharpest case was caught at the fact level in 12 of 227 cases, while the geometry vote missed it in all 227. Detail: docs/logic-layer.md, docs/margin-collapse-experiment.md.
• The economics question is now partly measured, not just estimated. About 55–60% of engine-relevant browser-compat-data entries are generatable from spec prose with a usable automated oracle, once conformance suites, fake-device hooks, reference libraries and script-observable traces are counted alongside the three-engine geometry vote; four of those areas — canvas 2D, WebGL, Web Audio and WebGPU, above — are now measured rather than estimated, and carrying the measurements in leaves the headline figures where they were: the share with no usable oracle stays at roughly 8–18%, moved by less than a point. Converted from tests to compat entries, a test at least two engines pass names 80.0% of canvas entries (93.5% outside the CSS Paint API), 97.8% of WebGL's and 83.3% of Web Audio's. Depending on Stylo for style and the cascade is judged an acceptable, process-level risk given an exact version pin and a single adapter crate. Detail: docs/platform-economics.md, docs/oracle-coverage.md, docs/stylo-risk.md.

Open questions and ideas #

• Whether a generated engine's feature set can be scaled up or down per use case, down to a standalone engine scoped to one app's content, is designed; its Stage 0 analyser has landed, the rest is not yet built: docs/content-scoped-engine.md.
• How computed style should be stored behind the spec-named accessors the substrate exposes (grouped, shared and refcounted looks like the convergent answer) matters only once Stylo is replaced. roadmap.md → "Open questions".
• How much of WPT is reachable without running JavaScript is unmeasured. roadmap.md → "Open questions".
• Where the line falls, per interface, between what IDL determines mechanically and what needs a prose-derived implementation is not yet mapped. roadmap.md → "Open questions".
• How each platform area is built and checked, area by area: docs/platform-areas.md.

Sources #

• web specifications all in one repo, constantly updated: https://github.com/w3c/browser-specs
• the web features project - all web apis (from bcd), curated into logical features: https://github.com/web-platform-dx/web-features/
• browser compat data - every tiny bit of every piece of the web surface area: https://github.com/mdn/browser-compat-data
• wpt - validation and verification of web implementation: https://web-platform-tests.org/
• wpt-gen - generate wpt test from the specification: https://github.com/GoogleChromeLabs/wpt-gen