The web profiler's downloadable HTML report ("Download report (HTML)" button) silently omits the reference-baseline comparison section that both the live on-page results and the Python CLI's equivalent report include.
Python side (faircode/report.py::to_html, lines ~181-198): explicitly renders a .reference section per dimension when a reference baseline was supplied, with matching CSS (lines ~257-260). Verified: faircode profile data.csv --reference baseline.csv --html out.html produces an HTML file containing the <div class="reference"> block with per-group expected/actual/delta rows.
JS side (assets/profiler-ui.js): there are two separate HTML-building code paths -
dimCard() (lines ~265-320) renders the live on-page results and correctly includes the reference comparison (checks d.reference, lines ~303-315).buildHtmlReport() (lines ~486-549), which builds the standalone downloadable file, never references d.reference at all - no CSS rule, no reference rows, nothing. Confirmed directly against the raw file content (not via grep, which is unreliable on some of these JS files due to embedded null bytes elsewhere in the codebase): d.reference appears exactly 3 times in profiler-ui.js, all inside dimCard(), zero inside buildHtmlReport().
Impact: a user who uploads a reference baseline in the web profiler sees the "vs reference" comparison live on the page, but the file they download to save/share drops it - while the equivalent Python CLI output (faircode profile --reference ... --html ...) includes it. This is a real parity gap, distinct from the already-known/intentional flags-field formatting difference between the two engines.
Proposed fix: port the reference-section rendering from dimCard() (or from faircode/report.py::to_html's HTML structure, whichever is closer to buildHtmlReport()'s existing style) into buildHtmlReport(), plus the matching CSS. faircode/SPEC.md should note that report-rendering parity extends to this section explicitly, if it doesn't already.
The web profiler's downloadable HTML report ("Download report (HTML)" button) silently omits the reference-baseline comparison section that both the live on-page results and the Python CLI's equivalent report include.
Python side (
faircode/report.py::to_html, lines ~181-198): explicitly renders a.referencesection per dimension when a reference baseline was supplied, with matching CSS (lines ~257-260). Verified:faircode profile data.csv --reference baseline.csv --html out.htmlproduces an HTML file containing the<div class="reference">block with per-group expected/actual/delta rows.JS side (
assets/profiler-ui.js): there are two separate HTML-building code paths -dimCard()(lines ~265-320) renders the live on-page results and correctly includes the reference comparison (checksd.reference, lines ~303-315).buildHtmlReport()(lines ~486-549), which builds the standalone downloadable file, never referencesd.referenceat all - no CSS rule, no reference rows, nothing. Confirmed directly against the raw file content (not viagrep, which is unreliable on some of these JS files due to embedded null bytes elsewhere in the codebase):d.referenceappears exactly 3 times inprofiler-ui.js, all insidedimCard(), zero insidebuildHtmlReport().Impact: a user who uploads a reference baseline in the web profiler sees the "vs reference" comparison live on the page, but the file they download to save/share drops it - while the equivalent Python CLI output (
faircode profile --reference ... --html ...) includes it. This is a real parity gap, distinct from the already-known/intentionalflags-field formatting difference between the two engines.Proposed fix: port the reference-section rendering from
dimCard()(or fromfaircode/report.py::to_html's HTML structure, whichever is closer tobuildHtmlReport()'s existing style) intobuildHtmlReport(), plus the matching CSS.faircode/SPEC.mdshould note that report-rendering parity extends to this section explicitly, if it doesn't already.