Bez: 仕様とテストからブラウザエンジンを生成する

Bez - 生成されるウェブエンジン 仕様とテストからウェブレンダリングエンジンを生成する なぜか ウェブエンジンを手作業で構築するには、数百人のエンジニアと長年の歳月が必要であり、そのため数社しかそれを所有できず、ウェブの仕組みを決定するのは彼らだけです。Bezは代わりにエンジンを生成します。仕様書から、3つの主要ブラウザ（互いに照合済み）とWPT（Web Platform Tests）をテストとして使用します。パイプラインが存在すれば、追加のエンジンはごくわずかなコストで済みます。 目標 完全なもの、またはツリーシェイクされたもの。デフォルトのビルドは完全なエンジンです。ウェブブラウザ以外の用途では、ビルドにはコンテンツが使用するウェブ機能のみを含めることができます。サイトやアプリを分析し、触れられない機能はバイナリから除外されます（docs/content-scoped-engine.md）。 あらゆるデバイスで高速に動作する。より小さなエンジンは、より少ない作業を行い、より少ないメモリを必要とします。 組み込みが容易。今日のChromium全体を出荷している、または何もなしで済ませているアプリやデバイスのために、明確なAPIを持つ小さなエンジンです。 更新が最も速い。仕様やテストが変更された場合、影響を受けるコードは手書きで書き直されるのではなく、再生成され、再検証されます。 仕組み フローチャート LR spec["spec text"] --> model["model writes<br/>many candidates"] model --> engine["candidate runs<br/>inside the engine"] browsers["Chromium, Firefox,<br/>WebKit (cached)"] --> check{"same boxes,<br/>same places?"} engine --> check check -- no --> model check -- yes --> code["committed as<br/>ordinary Rust"] docs/generation-loop.md — 1つのルールが仕様テキストからコミットされたコードになるまでの方法。 docs/geometry-verification.md — エンジンのレイアウトが3つのブラウザに対してどのようにチェックされるか。 docs/generated-functions.md — これまでに生成されたレイアウトルールと、各バッチが示したもの。 roadmap.md — 計画、決定事項、未解決の質問。 ステータス 2026-10-02時点で、browser-compat-data 8.0.4（17259リーフキー、docs/feature-map.jsonに76ルール）に対して計算済み。 エリア 生成済み 手書き リンク済み オラクル のみ 未到達 全体 0.6% 0.3% 0.5% 5.7% 93.0% CSS 2.5% 1.1% 2.0% 0.0% 94.4% HTML 0.0% 0.0% 0.0% 0.0% 100.0% API 0.0% 0.0% 0.0% 9.9% 90.1% JavaScript 0.0% 0.0% 0.0% 0.0% 100.0% SVG 0.0% 0.0% 0.0% 0.0% 100.0% WebAssembly 0.0% 0.0% 0.0% 0.0% 100.0% HTTP 0.0% 0.0% 0.0% 0.0% 100.0% MathML 0.0% 0.0% 0.0% 0.0% 100.0% これらのステータスが何を意味し、このテーブルがどのように同期されているかについては、docs/dashboard.mdを参照してください。 DOM、スタイル、ボックスツリー、フラグメントツリーは、crates/domおよびcrates/layoutで手書きされており、ブラウザチェックに合格しています（roadmap.md → "Phase 1 — Engine bootstrap"）。 9つのCSS 2.1レイアウトルールは、crates/layout/src/generatedにあります。8つはモデルによって記述され、3ブラウザの投票で承認されました。ブロックの高さは、モデル候補がそれを上回らなかったため、手書きのルールを維持しています。これらを合わせると、227のレシピケースと、通常のフローの11の利用可能なWPTページすべてに合格します。 エンジンが実際に呼び出すルール：roadmap.md → "Which resolver each generated function runs"。 この論文の主張を証明するもの：roadmap.md → "Proof of concept"。 これまでの発見 3つのブラウザはほとんど合意しており、3番目のブラウザが例外を特定します。235のドキュメントにわたる699/705のブラウザペア比較が合意しました（コミット3ca7323）。すべての6つの不一致は12階層のパーセンテージネストであり、多数決は常にFirefoxを例外と名指ししました。docs/firefox-app-units.md。 そのFirefoxの違いは、実際のウェブ互換性のバグです。Geckoは長さを1/60 pxに丸めますが、BlinkとWebKitは1/64 pxを使用するため、flexアイテムはFirefoxでのみラップするか、offsetWidthが1ピクセル異なります。再現は、Slack、Google Store、SamsungでのMozilla診断による破損、およびMozillaバグ1719314と一致します。experiments/firefox-compat/。 WPTの投票テーブルは、スイートのほとんどで合意しています。安定した3エンジン多数決は、2,282,301のテスト/サブテストキーのうち2,162,676（94.8%）をカバーします。docs/wpt-votes.md。 スクリプトで観測可能な動作も合意しています。偽メディアプロファイル下のトレースプローブは、18のエンジンペアのうち15で合意しています。3つの不一致は、実際のプラットフォームの違いです。docs/dump-format.md → "Trace protocol"。 適合性スイートは有用なオラクルです。2/3のエンジンが合意した場合にテストを利用可能とカウントする：WPT Canvas 82.6%（暫定を除く92.7%）、Khronos WebGL with dEQP 99.7%、WPT Web Audio 74.4%（暫定を除く85.6%）。WebGPU CTSは、検証で約85%、数値実行で約50%です。docs/conformance-oracles.md, docs/webgpu-cts.md。 論理プログラミングは狭い場所を確保します。Datalogとして記述されたマージンコラプシングは、1195/1195のオフセットでブラウザと合意し、ジオメトリチェックが227のすべてのケースで逃したシードされたバグを検出しました。docs/logic-layer.md。 経済性はプラットフォームのサブセットに対して成り立ちます。エンジン関連の互換性エントリの約55〜60%には、利用可能な自動オラクルと生成可能な仕様の散文があります。約8〜18%にはありません。docs/platform-economics.md, docs/oracle-coverage.md。 1つのサイトのコンテンツにスコープされたエンジンが設計され、そのコンテンツアナライザーが実装されました。docs/content-scoped-engine.md。 未解決の質問 各ルールを手作業で構築するコスト、機能の生成部分の幅、WPTのどの程度がJavaScriptなしで到達可能か、IDL生成コードがどこで終わるか：roadmap.md → "Open questions"。 エリアごとのステータス：docs/platform-areas.md。 ソース browser-specs、1つのリポジトリにあるすべてのウェブ仕様：https://github.com/w3c/browser-specs web-features、機能にグループ化されたウェブプラットフォーム：https://github.com/web-platform-dx/web-features/ browser-compat-data、ウェブサーフェスのすべての部分：https://github.com/mdn/browser-compat-data WPT、ウェブプラットフォームテスト：https://web-platform-tests.org/ wpt-gen、仕様から生成されたWPTテスト：https://github.com/GoogleChromeLabs/wpt-gen webref、ウェブ仕様からの機械可読用語：https://github.com/w3c/webref