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 `