Chapter 66 Web III: Six Renderers, Four Kinds of Evidence

Build evidence

The selected implementation compiled and linked to WebAssembly.

Host-start evidence

A JavaScript host loaded the module far enough to execute startup.

Structural evidence

A real browser observed renderer-specific DOM or SVG objects and invariants that another renderer could not trivially impersonate.

Pixel evidence

A real browser compositor produced sampled colors at expected screen positions.

Higher rungs include more of the delivery chain but do not erase lower-level tests. A pixel sample may prove presentation while missing a malformed object tree; a structural assertion may prove the renderer identity while missing blending. The strongest suite combines both.

HTML-DOM has the only genuine Web workflow at the audited revision. The workflow pins emsdk 6.0.3, installs Playwright with Chromium, builds the renderer, and serves six pages over HTTP. The harness waits for a verdict on window, because a WebAssembly process exit code is not observable in the same way as a native child process.

The browser driver also samples the real compositor. It takes a screenshot, transfers it back into an in-page canvas, and calls getImageData. Four point samples across its smoke and pixel cases use bounded RGB tolerances. This route is important: inspecting the renderer-owned DOM alone would not prove what Chromium finally composed on screen.

A separate host-integration case rewrites the HTML response with Playwright page.route(). It verifies that CNA refuses to seize host-owned DOM and does not create its viewport. Earlier injection through addInitScript was measurably too late, so the test modifies the document before module bootstrap. The timing mechanism is part of the proof.

SVG-DOM has a browser driver and 34 checks across three pages. It verifies SVG namespace identity for the root and its flush-slot descendants, keeps the SDL canvas hidden, and performs a four-point scissor-order pixel check. Those namespace assertions are anti-spoofing evidence: an HTML or canvas renderer cannot satisfy them merely by producing a similar picture.

Its shell browser runner still has no direct CI/CTest caller. Alpha.1 does add an Emscripten multi-renderer workflow that compiles and links WEBGL2, Canvas, HTML-DOM and SVG-DOM into one Wasm bundle and checks four generated-registry entries. That job explicitly does not launch a browser. SVG-DOM therefore has a reproducible manual browser route and an automatic bundle/link route, not a continuous SVG compositor test.

Both WebGL identities have reached Emscripten builds, but neither was run in a browser in the audited campaign. A bare-Node attempt stopped at window is not defined; that is host- environment evidence only. In particular, generated GLSL for WEBGL1 has not been compiled by an actual WebGL 1 implementation.

This leaves essential questions open: context creation, shader-version compatibility, buffer uploads, presentation, and context loss. The source contains context-loss handling, but source presence is not a recovery test. A browser test must deliberately lose and restore the context and then demand a fresh, visible frame.

The Canvas renderer also builds, but its bare-Node run fails during SDL initialization. Its manual browser checklist remains unchecked. The result is therefore build evidence, not browser execution evidence, and certainly not pixel evidence. The correct next test is not another Node invocation; it is an HTTP-served browser page with an explicit verdict and a small compositor sample.

The tag adds the Emscripten-only PIXIJS identity, pinned to PixiJS 7.4.2 with a recorded download hash. It adapts SpriteBatch, SpriteFont, scissor/blend state, textures and one RenderTarget2D to Pixi objects while refusing 3D, compiled/custom effects, MRT, cube and volume resources and queries. Neither the HTML-DOM workflow nor the four-renderer bundle workflow selects PIXIJS. Its tag evidence in this edition is source/configuration evidence; an HTTP-served browser test must still prove artifact resolution, object lifetime and compositor pixels.

The table is deliberately asymmetric. “Builds” says nothing about frame one, and four samples say nothing about complete rendering parity. It nevertheless gives each claim a precise meaning and exposes the shortest path to stronger evidence.

All six identities can converge on one harness pattern: serve artifacts over loopback HTTP; wait for a named window verdict with a timeout; fail on console errors and page exceptions; assert a renderer-specific structural token; sample a few compositor pixels; and archive the page log plus screenshot. Renderer-specific tests then add shader compilation, context restoration, DOM ownership, or canvas behavior.

The central rule is simple: prove that the intended runtime engaged. A green build can be produced without a browser, a green page can be produced before a frame, and a plausible image can be produced by the wrong rendering route. Identity, execution, and visible output are three separate facts, so the evidence should contain all three.