Bez Generates a Browser Engine from Web Specifications and Tests

Bez is a project to build a browser engine from web specifications, using tests and comparisons with existing browsers to check the results. An article about it was published on October 1, 2026. Its coverage table reflects a measurement taken on October 4, but the article does not say when the table was added. Sites and apps do not need to change anything yet: the project is at an early stage.

How the engine code is tested

A model receives the text of a specification and proposes ways to implement a rule. The candidates are run in Bez, and their element layouts are compared with the results from Chromium, Firefox, and WebKit. If a candidate fails the check, the cycle repeats. The accepted implementation is saved as ordinary Rust code. The checks also use Web Platform Tests (WPT).

The project uses the three browsers as references for behavior, not as sources of code. Their results are checked against one another so that a quirk of one engine does not become the model for the new one. In a study of 235 documents, 699 of 705 pairwise comparisons matched. All six discrepancies involved deeply nested percentage-based sizes; Firefox was the outlier when the three browsers were compared.

For WPT, a stable majority among the three engines was found for 2,162,676 of 2,282,301 tests and subtests—94.8%. That is the share of checks with an agreed reference result, not the share of tests Bez passes. Even a majority does not settle every difference: Gecko rounds lengths to 1/60 of a pixel, while Blink and WebKit round them to 1/64. As a result, a flex item may wrap only in Firefox, or offsetWidth may differ by a pixel.

How much has been implemented

In the table based on browser-compat-data 8.0.4, measured on October 4, 2026, 0.6% of entries are marked as generated and 0.3% as written by hand; work has not yet reached 93.0%. For HTML, JavaScript, SVG, WebAssembly, HTTP, and MathML, 100% of entries are listed as not yet reached. The table describes coverage of a feature map, not the share of sites Bez can open.

The DOM, styles, layout trees, and fragment trees were built by hand and pass the project's cross-browser checks. Of nine CSS 2.1 layout rules, eight model-proposed implementations were accepted after those comparisons. The hand-written version was kept for block element height: no candidate outperformed it. Together, the rules pass 227 prepared cases and 11 usable WPT pages for normal flow.

The project envisages both a full engine and a version tailored to the content of a particular site or app. In the latter case, an analyzer identifies which features are used so the rest can be left out of the binary. The analyzer has already been added, but the article does not report a ready-to-use lightweight build.

The method itself has limits. The project estimates that about 55–60% of engine-related compatibility entries have both an automated check and specification text suitable for generation. About 8–18% have neither. Open questions include the cost of implementing rules by hand, the size of generated components, and how much of WPT can be run without JavaScript. No release date for a full engine has been given.

What this means for sites and developers

Site owners do not need to revise project requirements or plan for Bez support. For now, the practical lesson lies elsewhere: browser behavior can be measured for consistency, but testing a page in just one browser will not reveal every discrepancy. The rounding example shows that differences can arise even in familiar CSS layouts.

For developers of apps and devices that need to display web content, a build containing only the features they use looks promising. But a content analyzer is not the same as a small engine ready to maintain. The reported results demonstrate that individual layout rules work, not that the web platform is fully supported.

My take

I like the idea of checking not just the generated code but the reference result itself: browsers really can disagree. At the same time, it is easy to mistake 94.8% for a measure of how ready Bez is. The coverage table quickly puts the scale of the remaining work back into perspective.

I would watch how many rules can be turned into working code and who will resolve conflicts between specifications, tests, and browsers. Until the cost of maintenance is clear, the promise of adding new parts of the engine cheaply remains a hypothesis.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Bez: Generating a browser engine from specs and tests tangled.org

About the author

Raúl Martín

Senior full-stack developer

I design and maintain web applications; in recent years I've spent more time untangling legacy code than starting from scratch. Before choosing a technology, I ask who will maintain it.

All posts by the author