| REFERENCE-DISPUTED | interactions | interactions-cartesian-page-margins-x-paged-media | supported-family-cartesian-product · colour-only residual · PageCount · above-floor diff 100.00% · raw RGBA diff 100.00% · reference dispute: CSS Fragmentation 3 sections 3.1 and 4.3 require break-before:page on the nested in-flow block to force a class-A page break and move the ensuing content into the next page fragmentainer. Ironpress therefore emits four pages and slices the outer box across pages 2 and 3. Chromium 150 Foundation ignores that forced break, emits three pages, and overlaps the nested text with its preceding sibling on page 2. Its PDF remains a compatibility canary rather than a normative fragmentation oracle; the complete shared-pdftoppm page-count and raster evidence remains reported. · page-count mismatch: ironpress 4 vs oracle 3 |
| REFERENCE-DISPUTED | filters | r2-filter-url-feturbulence-displacement | filter: url(#id) with feTurbulence and feDisplacementMap · colour-only residual · ColorValue · above-floor diff 3.18% · raw RGBA diff 3.20% · 10068 differing RGBA pixels · reference dispute: Filter Effects 1 section 9.21 supplies the exact feTurbulence algorithm: zero and over-length random gradient vectors are rejected and consume a new pseudorandom pair. Chromium PDF and Firefox screen output instead agree with the legacy normalize-every-pair field; authored position controls confirm Chromium still uses the required local coordinate system. Its PDF is therefore a compatibility canary, not a normative pixel oracle. · fill recolour ΔRGB(-3,-42,-42) (ΔE 45.7) |
| REFERENCE-DISPUTED | paged-media | paged-footnote-max-height | footnote · direct paint mismatch · Missing · above-floor diff 1.81% · raw RGBA diff 2.05% · 6021 differing RGBA pixels · reference dispute: CSS GCPM limits the footnote area with max-height except on a page containing only footnotes, and footnote-policy:auto permits the body to move to a later page. Both PDFs keep the call on page 1, move the complete body to the footnote-only page 2, and preserve the same three-line wrapping and rule geometry. Every body line in the WeasyPrint PDF is uniformly 0.1157pt lower; horizontal word bounds differ by at most 0.028pt. That renderer-specific baseline and glyph quantization is not prescribed by GCPM, so the WeasyPrint PDF is not a unique pixel oracle; raw shared-pdftoppm evidence remains reported. · page 2: candidate lacks paint present in reference (5.1%) |
| REFERENCE-DISPUTED | inline-text | inline-text-text-decoration-wavy | text-decoration-style:wavy · direct paint mismatch · Missing · above-floor diff 2.05% · raw RGBA diff 2.05% · 5332 differing RGBA pixels · reference dispute: CSS Text Decoration 4 section 2.2 requires only a wavy line, not Chrome's wavelength, amplitude, or jagged curve; Ironpress and WeasyPrint render different smooth waves. · candidate lacks paint present in reference (21.9%) |
| REFERENCE-DISPUTED | paged-media | footnote-float | footnote · direct paint mismatch · Missing · above-floor diff 1.99% · raw RGBA diff 2.03% · 23746 differing RGBA pixels · reference dispute: CSS GCPM 3 section 2.6 defines the default footnote call as a superscripted counter with vertical-align:baseline, font-size:100%, line-height:inherit, and font-variant-position:super. Ironpress emits that superscript without moving the body line; WeasyPrint leaves the call full-size on the baseline, so its PDF is a compatibility canary, not a normative pixel oracle. · candidate lacks paint present in reference (26.1%) |
| REFERENCE-DISPUTED | paged-media | paged-footnote-display-compact | footnote · colour-only residual · AntialiasCoverage · above-floor diff 1.78% · raw RGBA diff 1.83% · 5507 differing RGBA pixels · reference dispute: CSS GCPM requires both fitting compact footnotes to share one inline footnote-area line at the page-area bottom, which both PDFs do. Ironpress preserves a 76.5pt separation between the body and footnote baselines; WeasyPrint preserves the same separation but shifts both by 0.1157pt. Chromium rendering of the independent standards-derived source matches Ironpress within 0.0021pt. The remaining raw signal is renderer-specific text contour and baseline quantization, not compact-footnote placement, so the WeasyPrint PDF is not a unique pixel oracle. · above-floor complete-page mismatch 1.777371% exceeds 1.0% PASS ceiling; visually accepted coverage phase; raw antialiasing coverage residue on a shared outline |
| REFERENCE-DISPUTED | backgrounds-borders | background-clip-text-gradient | background-clip · colour-only residual · AntialiasCoverage · above-floor diff 1.57% · raw RGBA diff 1.58% · 4554 differing RGBA pixels · reference dispute: CSS Backgrounds 4 defines background-clip:text by the text geometry, not a text-edge sampling grid or PDF representation. Chromium's PDF turns the matched ParitySans outlines into a 196x83 soft-mask image; Ironpress retains the same outline geometry as a vector text clip. The gradient interior and glyph positions agree, but the two valid edge-coverage strategies cannot be a unique pixel oracle. · above-floor complete-page mismatch 1.565714% exceeds 1.0% PASS ceiling; visually accepted coverage phase; raw antialiasing coverage residue on a shared outline |
| REFERENCE-DISPUTED | generated-content | generated-content-string-set-running-header | string-set and string() · direct paint mismatch · Missing · above-floor diff 1.20% · raw RGBA diff 1.47% · 5873 differing RGBA pixels · reference dispute: CSS GCPM requires string-set to capture the heading and string() to reproduce it in the page-margin box; it does not prescribe renderer-specific glyph quantization. Both PDFs contain the complete Running Head on both pages. On page 1 Ironpress places its header bbox at x=47.8125..132.1758pt, y=4.2683..18.2243pt, versus WeasyPrint x=47.8184..132.2024pt, y=4.2683..18.2363pt. The residual is a text-contour representation difference, so this WeasyPrint PDF is not a unique pixel oracle; raw shared-pdftoppm evidence remains reported. · candidate lacks paint present in reference (3.0%) |
| REFERENCE-DISPUTED | effects | r2-mix-blend-mode-text-difference | mix-blend-mode on text · colour-only residual · AntialiasCoverage · above-floor diff 1.27% · raw RGBA diff 1.27% · 3576 differing RGBA pixels · reference dispute: Both PDFs are rasterized by the same pinned pdftoppm command. Ironpress applies difference to the text: its fully painted glyph colour is Chrome's #EA9A3F over the #1565C0 backdrop (27,453 versus 27,471 pixels). The remaining raw diff is only one-device-pixel glyph-contour coverage. Ironpress embeds ParitySans as CID TrueType while Chrome's PDF uses Type 3, which changes PDF edge coverage under the shared rasterizer without indicating a missing blend-mode operation. Raw evidence remains reported. · above-floor complete-page mismatch 1.271467% exceeds 1.0% PASS ceiling; visually accepted coverage phase; raw antialiasing coverage residue on a shared outline |
| REFERENCE-DISPUTED | color-opacity | opacity-text-glyph-group | opacity · colour-only residual · AntialiasCoverage · above-floor diff 1.09% · raw RGBA diff 1.14% · 3804 differing RGBA pixels · reference dispute: Both PDFs are rasterized by the same pinned pdftoppm command. Ironpress composites the overlapping glyphs as one opacity group: its fully painted glyph colour is the same #808080 as Chrome's (52,577 versus 52,595 pixels), so the overlap is not brightened by per-glyph alpha. The remaining raw diff is a one-device-pixel contour residue. The Ironpress PDF embeds ParitySans as CID TrueType while Chrome's PDF uses Type 3, so their PDF glyph programs produce slightly different edge coverage in that shared rasterization. This does not indicate missing opacity-group support; raw evidence remains reported. · above-floor complete-page mismatch 1.090827% exceeds 1.0% PASS ceiling; visually accepted coverage phase; raw antialiasing coverage residue on a shared outline |
| REFERENCE-DISPUTED | tables | tables-colspan-max-clamp | html-table-attributes · direct paint mismatch · Extra · above-floor diff 1.14% · raw RGBA diff 1.14% · 3731 differing RGBA pixels · reference dispute: HTML clamps the first cell to 1000 columns, then forms a 1001st track for the following cell. CSS Tables fixed layout preserves every column and distributes unspecified-track width equally; Ironpress keeps that subpixel trailing cell, while Chromium gives it an 8px minimum and Firefox does not. The Chromium PDF is a compatibility canary, not a normative pixel oracle. · candidate adds paint absent from reference (1.0%) |
| REFERENCE-DISPUTED | interactions | interactions-cartesian-effects-x-paged-media | supported-family-cartesian-product · colour-only residual · ColorValue · above-floor diff 0.80% · raw RGBA diff 0.80% · 2985 differing RGBA pixels · reference dispute: CSS Fragmentation 3 section 5.4 requires box-decoration-break:slice to render the unbroken box and then slice it, with no box-shadow drawn at a broken edge. WPT box-shadow-002 tests that rule directly, while box-shadow-005 reserves a shadow around every fragment for box-decoration-break:clone. Ironpress leaves the page 2/3 cut undecorated; Chromium paints the yellow inset-shadow band at both cut edges as if the fragments were cloned. Its PDF remains a compatibility canary, not a normative oracle, and the raw shared-pdftoppm evidence remains reported. · page 2: fill recolour ΔRGB(-24,+36,+153) (ΔE 33.3) |
| REFERENCE-DISPUTED | generated-content | generated-content-first-letter-dropcap | first-letter · colour-only residual · ColorValue · above-floor diff 0.52% · raw RGBA diff 0.52% · 4602 differing RGBA pixels · reference dispute: Ironpress and Chrome have the same floated initial letter, text wrapping, and line sequence. Ironpress matches WeasyPrint's normal-line origins (for example 28.397869pt versus 28.397871pt) while Chrome uses 28.076659pt; the remaining raw divergence is renderer-specific first-letter glyph geometry. CSS Pseudo-Elements specifies the float and allowed styling, not a Chrome-specific glyph bounding box. Raw shared-pdftoppm evidence remains reported. · fill recolour ΔRGB(+1,+1,+1) (ΔE 27.8) |
| REFERENCE-DISPUTED | overflow-clipping | overflow-scroll-print-clip | overflow · direct paint mismatch · Missing · above-floor diff 0.44% · raw RGBA diff 0.47% · 2554 differing RGBA pixels · reference dispute: CSS Overflow 3 section 3.1.3 allows static-media UAs to show an overflow indication and says overflowing scroll content may be printed without defining where; Chrome's exact scrollbar and clipping pixels are not a normative oracle. · candidate lacks paint present in reference (0.6%) |
| REFERENCE-DISPUTED | overflow-clipping | overflow-axis-visible-hidden-coercion | overflow · direct paint mismatch · Missing · above-floor diff 0.30% · raw RGBA diff 0.34% · 888 differing RGBA pixels · reference dispute: CSS Overflow 3 section 3.1 makes visible compute to auto when the other axis is scrollable, which Ironpress implements. In print, auto inherits scroll's undefined overflow placement, so Chrome's scrollbar geometry and clipping pixels are a compatibility canary, not a normative oracle. · candidate lacks paint present in reference (0.3%) |
| REFERENCE-DISPUTED | lists-counters | lists-counters-marker-side-match-parent | marker-side:match-parent · direct paint mismatch · Missing · above-floor diff 0.24% · raw RGBA diff 0.24% · 1274 differing RGBA pixels · reference dispute: CSS Lists 3 leaves the exact position of outside marker boxes undefined. This fixture does not vary list-item directionality, so match-parent has no observable effect. Chromium 150 reports CSS.supports('marker-side: match-parent') as false and an empty computed value; its PDF is an unsupported-feature compatibility canary, not a normative oracle. · candidate lacks paint present in reference (0.2%) |
| REFERENCE-DISPUTED | overflow-clipping | overflow-x-y-separate | overflow · direct paint mismatch · Extra · above-floor diff 0.23% · raw RGBA diff 0.23% · 1203 differing RGBA pixels · reference dispute: CSS Overflow 3 section 3.1 makes visible compute to auto when the other axis is scrollable, which Ironpress implements. In static media, section 3.1.3 permits a UA overflow indication and section 5.1 leaves its appearance, size, and edge UA-defined; Chrome's scrollbar pixels are a compatibility canary, not a normative oracle. · candidate adds paint absent from reference (0.3%) |
| REFERENCE-DISPUTED | interactions | interactions-cartesian-positioning-x-tables | supported-family-cartesian-product · colour-only residual · ColorValue · above-floor diff 0.19% · raw RGBA diff 0.19% · 1913 differing RGBA pixels · reference dispute: CSS Tables 3 section 4.1 defines the containing block generated by a positioned table wrapper as the area around which table margins are applied, explicitly including the area where the table border is drawn. Ironpress positions the absolute Bb from that border edge. Both the locked Chromium 150.0.7871.114 Foundation PDF and a fresh Chromium 150.0.7871.128 Foundation PDF instead inset it by the authored 2px table border on both axes; the specification identifies this behavior as a Chromium bug and interoperability risk. The Chromium PDF remains a compatibility canary rather than a normative geometry oracle, and the raw shared-pdftoppm evidence remains reported. · fill recolour ΔRGB(-2,-2,-2) (ΔE 69.2) |
| REFERENCE-DISPUTED | text-advanced | text-advanced-text-combine-upright-digits | text-combine-upright:digits 2 · colour-only residual · ColorValue · above-floor diff 0.16% · raw RGBA diff 0.17% · 801 differing RGBA pixels · reference dispute: CSS Writing Modes 4 sections 9.1.2 and 9.1.3 require the composition's combined advance to fit within a measured 1em square and explicitly permit geometric compression. Ironpress follows that rule: each 24px two-digit composition occupies 18pt in the PDF. Chromium's LayoutTextCombine::DesiredWidth deliberately allows an undecorated composition 1.1em, with a source comment acknowledging that the margin is not specified; the locked PDF correspondingly uses a 19.8pt advance and outlines 10% wider than the standards-compliant candidate. Its surrounding CJK placement remains useful evidence, but its combined-glyph width is a compatibility canary rather than a normative appearance oracle. · fill recolour ΔRGB(+1,+6,+5) (ΔE 26.6) |
| REFERENCE-DISPUTED | text-advanced | text-advanced-text-combine-upright-center | text-combine-upright:digits 2 · colour-only residual · ColorValue · above-floor diff 0.14% · raw RGBA diff 0.15% · 701 differing RGBA pixels · reference dispute: CSS Writing Modes 4 sections 9.1.2 and 9.1.3 require the composition's combined advance to fit within a measured 1em square and explicitly permit geometric compression. Ironpress follows that rule: the 24px composition occupies 18pt in the PDF. Chromium's LayoutTextCombine::DesiredWidth deliberately allows an undecorated composition 1.1em, with a source comment acknowledging that the margin is not specified; the locked PDF correspondingly uses a 19.8pt advance and outlines 10% wider than the standards-compliant candidate. Its placement remains useful evidence, but its glyph width is a compatibility canary rather than a normative appearance oracle. · fill recolour ΔRGB(+5,+28,+22) (ΔE 27.7) |