From 87eaefdbb386428c9a2c7e859a101be67c8aa4a0 Mon Sep 17 00:00:00 2001 From: tannevaled Date: Sun, 18 Oct 2026 16:19:45 +0200 Subject: [PATCH] docs: correct FIDELITY.md -- block-in-inline promotion closed in round 38 "Known gaps" kept saying a block-level element nested under an inline- context ancestor (the /votearrow pattern) was flattened into plain text and "not attempted", citing architecture "comparable in scope to Shadow DOM". Round 38 (2026-09-05, engine#118) actually built this (InlineItem.BlockBreak + placeInlineSegments, following CSS 2.1 Section 9.2.1.1), with passing regression tests still green on current code -- confirmed live while drafting a plan to implement what turned out to already exist. The inline-flex entry repeated the same stale cross-reference ("needs the same mechanism this engine has never had"), even though its own opening sentence already said the mechanism existed and was wired in at round 148. Corrected both to point at the actual closing round instead of each other's now-six-week-old citation. Co-Authored-By: Claude Sonnet 5 --- FIDELITY.md | 67 ++++++++++++++--------------------------------------- 1 file changed, 18 insertions(+), 49 deletions(-) diff --git a/FIDELITY.md b/FIDELITY.md index f081fa4..ba349f0 100644 --- a/FIDELITY.md +++ b/FIDELITY.md @@ -5401,21 +5401,23 @@ columns. - **react.dev's own hydration fails with a real React error (#418, "the initial UI does not match what was rendered on the server"), which cascades into a SECOND, internal React crash during its own unmount/remount recovery and unmounts the whole app to nothing — this engine's own empty-page guard then falls back to the pre-hydration SSR skeleton, the long-documented "reskin gap."** Found live (round 82, 2026-09-22): this is a NEW, more precisely characterised failure mode, distinct from round 71's `ChunkLoadError` theory — confirmed unrelated by fixing round 71's own flagged root cause (`setTimeout` discarding its requested delay, fixed this same round) and re-checking: the live JS log was byte-for-byte identical before and after that fix. One plausible theory (a `prefers-color-scheme` client/server mismatch via `matchMedia`) was checked and ruled out — this engine already deliberately resolves that query to match react.dev's own dark-theme strategy. Minified production React strips the hydration-mismatch diff that would name the exact divergent DOM node, so finding the actual cause needs a materially larger investigation than fits in one round; not chased further, not fixed here. - **goja (this engine's JS runtime) does not support ES2018 `for await (... of ...)` asynchronous-iteration syntax.** Found live on tailwindcss.com (round 77, 2026-09-21): a real Next.js chunk shipped as a plain classic script (correctly recognised as such by this engine — no type-attribute mishandling involved) fails to compile at all because its own code legitimately uses `for await` inside a real `async function`. Isolated to the exact byte via the real fetched chunk, and reproduced from scratch with a minimal, from-nothing repro containing only the `for await` construct. Confirmed as a genuine, currently-open upstream gap (dop251/goja#498, "Upgrade to latest version of ECMAScript 2021/2022") rather than a local misconfiguration — there is no JS parser in this repo to patch; forking or patching goja itself is outside this engine's own scope. Not fixed, not fixable here. - **`display:inline-grid`/`inline-table` — re-checked round 148 (2026-10-04): the only corpus use of `inline-grid` is tailwindcss.com's header search button and theme switcher, both DIRECT CHILDREN of a `display:flex` container, where a flex item is blockified regardless — so the missing inline half has no visible effect on any corpus page. No confirmed trigger yet; revisit if one appears.** -- **Historical, partly fixed: `display:inline-flex` once lost its "inline" half.** `DisplayInlineFlex` now exists and `layout.go`'s `appendElementInline` lays it out as an atomic inline box with a `NestedBox` (verified round 148, 2026-10-04). The original report, kept for context: confirmed on TWO separate real pages for `inline-flex`: +- **Historical, now CLOSED: `display:inline-flex` once lost its "inline" half.** `DisplayInlineFlex` now exists and `layout.go`'s `appendElementInline` lays it out as an atomic inline box with a `NestedBox` (verified round 148, 2026-10-04). The original report, kept for context: confirmed on TWO separate real pages for `inline-flex`: github.com's header "Sign in"/"Sign up" buttons (round 24) and pkg.go.dev's breadcrumb `
  • `s (round 26, `.go-Breadcrumb li{display:inline-flex}`), where each list item stacks on its own line instead of flowing in a row with `>` separators between them (the separators are ALSO missing — a second, already-documented gap: `::before`/`::after` generated content is not synthesised at all, rank 5 in the original Phase-0 fidelity plan). - This is the SAME architectural gap as the ``-flattens- - block-content one below, from the opposite direction: there, a genuinely - block element nested in an inline context gets wrongly flattened into - inline text; here, a genuinely INLINE-outer element (by explicit author - CSS) gets wrongly treated as block-level. A real fix needs the same - "atomic inline-level box with a real box/layout inside" mechanism this - engine has never had (already deferred in round 24, comparable in scope - to Shadow DOM) — not attempted. + This was once filed as "the SAME architectural gap as the + ``-flattens-block-content one, from the opposite + direction" and "not attempted" — both stale by the time this correction + was made (2026-10-18): round 38 (engine#118, 2026-09-05) built exactly + the "atomic inline-level box with a real box/layout inside" mechanism + this bullet said the engine "has never had," and round 148 wired + `inline-flex` specifically through it. Left as a historical record of + how long a cross-referenced gap can keep citing a dependency that + closed weeks earlier without anyone reconciling the citation — see the + `` entry below, now also marked CLOSED. - **The third-party SVG rasteriser (`github.com/srwiley/oksvg`, pinned at its latest available commit) mis-renders at least one real-world complex multi-subpath vector ``.** Found live on developer.mozilla.org @@ -5493,46 +5495,13 @@ columns. than the font's own em box — so a large `line-height` makes the band taller than a browser's. -- **A block/flex/grid-level element nested under an inline-context ancestor - (e.g. an unstyled custom element, which defaults to `display:inline`) is - flattened into plain inline text instead of getting a real box.** Found - live on github.com/golang/go (2026-09-03, round 24, no code change): its - whole marketing header sits inside ``, a custom element - nothing styles — `layout.go`'s `appendElementInline` has no check for a - nested element's OWN display resolving to block-level, so it - unconditionally recurses via `appendInline`, losing box model/margins/flex - layout for everything inside (see the round-24 log entry above for the - concrete symptom: two adjacent buttons render glued together with no - gap). The correct fix — generating an anonymous block wrapper around such - a box and promoting it to a real sibling (CSS 2.1 §9.2.1.1) — is a real - layout feature comparable in scope to Shadow DOM slot projection, not a - narrow bug fix; not attempted. - **Confirmed a SECOND, independent real-world instance (2026-09-04, round - 33): news.ycombinator.com's own upvote-triangle icon.** Its markup is - `
    ` — a plain block - `
    ` (styled with a `background: url("triangle.svg"), linear- - gradient(...) no-repeat` icon, no text) nested directly inside an inline - ``. Root-caused with an isolated, network-independent reproduction - (`RenderHTML` against a minimal fixture): a background-image `url()` - layer on a standalone `
    {...}
    ` renders correctly (44 - non-background pixels of the expected triangle shape), and the SAME CSS - wrapped in the SAME `    ...` nesting the real page uses renders - ZERO — confirming the div's own box (and therefore its background paint - step) is lost inside the inline wrapper, not a background-image/SVG- - decoding defect. (An earlier bisection attempt wrongly suspected the - background-image pipeline itself, tracing a red herring caused by the - test fixture's OWN construction — an inline `style="..."` HTML attribute - containing a `url("data:...")` value whose embedded double quotes - collide with the attribute's own delimiter, truncating the attribute - value at HTML-parse time; switching the reproduction to a `