← product evidence + the ladder to state of the art

Nishi browser vs Chrome — run 2: the inline text-flow fix, before/after

workstream: S21 experiential / S18 graphics — browser chrome-parity ratchetrun: browser-parity-2026-07-16b2026-07-16

Verdict: Three measure-vs-paint drifts unified in one root arc (layout now reserves the exact widths the vector paint draws; paint now inherits font-size the same way layout does; both int parsers truncate at the decimal). Result you can see: Wikipedia link-gaps GONE, /experiential labels flow, the readability usability study is now PASS (100% task success, 1 cosmetic left). Chrome match overall: still NOT YET — heights 61%/106%, tight paint parity 57.3%/45.5% (font raster dominates that number; the flow fix is proven by the pixels and a contiguity gate, not by the parity delta).
evidence
Wikipedia, Nishi vs Nishi — BEFORE (left): every inline link surrounded by phantom gaps, the hatnote sprawls in fragments. AFTER (right): "Please help improve it or discuss these issues on the talk page…" flows like a real browser. Root cause: layout reserved bitmap-font widths while paint drew the narrower vector font; layout now sums the same font_adv_em metric paint advances by (gate: exact widths + contiguity). open full size
evidence
/experiential, Nishi vs Nishi — BEFORE (left): intro labels overlap the body text. AFTER (right): labels sit inline; the census table is single-line 13px rows with aligned headers. The fix chain also killed a paint-side wrap regression caught mid-arc: paint resolved font-size on the element only (default 16) while layout inherited 13 — paint now walks ancestors exactly like layout (br_comp_int_inh). open full size
evidence
/experiential after — Chrome (left) vs Nishi (right). Remaining visible deltas: pill shapes (no border-radius paint), vector face vs system font, bold-line placement. open full size
evidence
Wikipedia after — Chrome (left) vs Nishi (right). Remaining: image floats left overlapping text (float support queued), Wikipedia skin chrome not rendered, font raster. open full size
recording
RECORDING — the Nishi browser scrolling the Wikipedia article after the flow fix (4 viewports, top to ~2.5k px). Prev/play/next steps the actual captured frames. · frame 1

Measured

whatresultmeaning
Usability study (readability tasks)PASS — 100% task success, 0 major, 0 minor, 1 cosmeticArc across the day: FAIL 25% -> FAIL 50% -> CONDITIONAL 75% -> PASS 100%; every step forced by a gated root-fix; the anti-sticker controls stayed GREEN throughout
Inline flow correctnessnx_inline_vec_measure_gate GREEN 4/4Layout width == exact vector-advance sum (27px vs bitmap 34px for the fixture); next run starts exactly where the last ended; legacy bitmap mode byte-unchanged
Wikipedia layout height8037px vs Chrome 7582px (106%)Was 111% before the fix — narrower true widths = fewer wraps
/experiential layout height1367px vs Chrome 2227px (61%)Denser than Chrome: padding/margin shorthands + line-height still unsupported (queued, the height-axis rung)
Tight paint parity/experiential 57.3% · Wikipedia 45.5% (was 56.5/45.1)Honest read: this metric is dominated by font-rasterizer differences per cell, so a real flow fix moves it ~1 point; the proof of the fix is the before/after pixels + the contiguity gate, and the metric stays as the font-parity ratchet
Regression caught mid-arctable cells painted 2 lines over 1-line rowsThe fix itself exposed the third drift (paint font-size resolver); caught by re-seeing the recording, root-fixed same arc, all gates GREEN after
Gates after the arcinline-vec-measure 4/4 · fontsize-frac 4/4 · bg-cascade 4/4 · ux-study 4/4Every prior gate re-run GREEN — no silent regressions shipped

Machine detail: api.json · related: /evidence/browser-parity-2026-07-16