Compare semantic HTML and Wasm
Both previews compile the same shared feature sources, theme tokens, application-owned models and navigation recipes. Choose a viewport and feature to compare how each renderer responds. Open each preview separately for browser controls and full-window testing.
Wasm is an experimental visual comparison. Its stable CMP accessibility bridge has known role, state and modal limitations; choose semantic HTML for accessible web forms.
HTML demo · Wasm demo · Path URLs
The theme selector applies to the Material comparison scenes. Both frames receive the same explicit theme and component calls; the states scene shows enabled, disabled, checked, unchecked, mixed and slider endpoints together.
Semantic HTML · Kotlin/JS
Compose UI · Kotlin/Wasm
CI captures both the top and bottom of each component family so lower controls, including time pickers and wheels, remain covered. The states fixture also compares checkbox, switch, radio and slider hover, press and keyboard focus across the eight themes. The stable Wasm accessibility bridge exposes slider labels without their bounds, so those pointer captures use the shared fixture's measured HTML coordinates and native keyboard traversal. This is canvas interaction coverage, not semantic-slider accessibility support.
The side-by-side frames intentionally scroll horizontally when their selected viewport exceeds the space on this page. This preserves the chosen actual feature width, rather than scaling pixels and pretending it is a phone layout.
HTML renders semantic elements and native browser controls. Wasm renders Compose UI and offers different text, input and accessibility behavior. The isolated Material scenes remove application chrome so control geometry, palettes and states can be compared directly at equal viewports. Renderer comparison reports expose remaining differences; an independent golden image passing does not prove HTML/Compose parity. Text rasterization and platform input behavior still depend on the renderer. See the compatibility table for tested behavior, browser-history differences and current limitations.
Reproducible component comparisons
The Material routes pin the same regular, medium and bold Roboto font files in both hosts, so font metrics do not depend on the browser or operating system. The library does not bundle a font or change your native Material font family: configure native typography in the host and use the matching CSS family through DomposableMaterialTheme(typography = ...) for HTML. The comparison host demonstrates both sides.
CI captures all nine component families in eight themes at 390 px and 1280 px. It captures the beginning and end of long families, plus hover, press and keyboard focus for checkbox, switch, radio and slider. The resulting 464 HTML / pixel difference / Wasm panels are exported in the CI evidence artifact. These diagnostic panels complement regression baselines; producing an image does not establish visual parity.
The demo font files come from Roboto, with the Apache 2.0 license included in the demo resources. They apply only to comparison routes.
Wasm capture automation waits for positioned accessibility nodes and settled keyboard frames, then checks the painted focus ring before taking selection-control focus screenshots. Stable CMP can replace bridge nodes during layout; a connected DOM node alone does not establish native focus or valid bounds.