Bez tries to grow a browser engine from web standards, not ship one whole

Web pages today are drawn by a small handful of engines. Chromium, the open-source base of Chrome and Edge, runs Blink. Firefox runs Gecko. Safari runs WebKit. Shipping a new rendering engine from scratch has been famously expensive, which is why the roster has stayed short for decades.

Bez, a small open project on the code host Tangled, is testing whether that constraint is a cost-structure problem rather than a capability problem. The bet is simple to describe: write CSS layout code from the open web standards, then check each generated function against the three incumbent engines, accepting it only when they agree. By Bez's own account, the generated slice is narrower than the headline suggests. The project's documentation describes the generated functions as plain-data layout decisions that take a precomputed input tree and return numbers (a position, a size) with no DOM or Stylo access. (The DOM is the in-memory tree a browser builds for a web page; Stylo is Firefox's parallel styling engine.) Hand-written code in the surrounding codebase decides when each rule applies and prepares those inputs.

The verification step is the geometry harness, which compares each candidate's measurements against Chromium, Firefox, and WebKit, caches browser output, accepts a 1/60 pixel tolerance, and throws out cases where the three browsers disagree on scrollbar presence. That setup is a test oracle, not a certification. It can tell Bez when a generated rule matches what the incumbents already do, and it can tell the project when the incumbents do not agree. It cannot tell a reader that Bez is correct in a way the three browsers are not, because correctness here is defined as agreement with them.

As of a project receipt dated 2026-09-25, Bez's recipe-style cases pass 227 of 227, and its grammar cases pass 61 of 164, with another 36 discarded because the three browsers disagreed on scrollbars. A separate entry for absolute positioning reports 82 of 108 cases, with three categories still at zero. The main page shows overall coverage of 0.6% generated and 93.0% unreached against browser-compat-data 8.0.4, a public catalog of which web platform features each browser supports. The "Web Platform Tests" (WPT) is the community's shared test suite for those standards. On a held-out slice of WPT pages, Bez reports 7 of 7 passing on cases the project calls eligible; the same documentation separately limits the eligible set to 7 of 1056 normal-flow pages, and the two numbers are internally inconsistent, so each one should be held to its own wording rather than combined.

The project's cost log separates generated candidates from the hand-written scaffolding that drives the pipeline, but admits the agent-session tokens for that scaffolding were not metered, so a total development cost is not in the public record. The "generated functions" page lists twelve entries, but one of them is a table-layout placeholder and the height implementation is still hand-written, so a blanket claim that every listed function came out of the model would be wrong.

Bez is not arriving, but the project shows what a spec-to-code loop changes: a credible loop, even one checked against the incumbents rather than replacing them, lowers the bar to attempting a new engine. That puts Bez alongside other attempts to widen the field. Ladybird, an independent C++ engine maintained largely by one developer, has been working toward a usable browser for years. Servo, the Rust engine Mozilla archived, has been revived by a community fork. Each is a different bet on the same cost question. The falsifier for Bez sits in the surrounding scaffolding rather than the generation loop: whether the project can carry a security review, hold performance against the incumbents, and survive maintenance as the web standards themselves change.

The next dated checkpoint will be the next update to the project's coverage page, where the ratio of generated to unreached moves, or does not.