feat(webui): rem type scale — respect browser font-size (stacked on #248) - #249
Closed
srikanth-bitdynamics wants to merge 1 commit into
Closed
feat(webui): rem type scale — respect browser font-size (stacked on #248)#249srikanth-bitdynamics wants to merge 1 commit into
srikanth-bitdynamics wants to merge 1 commit into
Conversation
Follow-up to the px ramp (#248, its base branch). That PR put every size on the docs-site ramp but kept them as fixed px, so the Web UI ignored the reader's browser/OS font-size preference — the docs site (rem-based) honors it, the app didn't. Introduce the ramp as a named `fs` scale in tokens.ts, in rem: fs.caption 0.6875rem (11) fs.small 0.8125rem (13) fs.body 1rem (16) fs.h3 1.125rem (18) fs.h2 1.375rem (22) fs.h1 1.75rem (28) - Every inline fontSize (object + SVG-attribute) now references fs.*. - index.css root flips from `font-size: 16px` to `100%` so rem tracks the browser default — this is what actually enables user scaling. - MonoId's `size` prop becomes a string defaulting to fs.small; callers updated. At the default 16px root this renders pixel-identical to #248. When a reader has bumped their browser/OS font size (or on the accessibility "large text" setting), the whole app now scales with it — verified live by setting the document root to 22px and watching every surface grow proportionally. tsc clean, vitest 218 green. No behavior change beyond typography.
srikanth-bitdynamics
added a commit
that referenced
this pull request
Jul 11, 2026
Adopts #249's accessibility approach — a named rem `fs` scale in tokens.ts so the console honors the browser/OS font-size — on top of #250's role-aware sizing. The root is now 100% and every inline fontSize references an fs.* token, so operational data stays dense, prose reads larger, and the whole UI scales with the reader's font-size preference. - New `fs` rem scale: micro/label/meta/data/body/lead/strong/title/stat. - ~440 inline fontSize px literals -> fs tokens (value-preserving, so the approved hybrid sizing is unchanged); MonoId and chart labels included. - index.css root -> 100%, its font-sizes -> rem. Combines what #248 (flat px) and #249 (flat rem) each had half of. tsc + 218 frontend tests green.
Collaborator
Author
zheli
pushed a commit
that referenced
this pull request
Jul 11, 2026
…le (#250) * style(webui): hybrid type scale — bump prose, keep data dense Refines the flat 16px bump into a role-aware scale for a console that is scanned and operated, not read top to bottom. Only prose grows; operational data stays at its tight baseline so dense tables, metric values, and mono IDs keep their density. - Page titles -> 22, descriptions -> 15 - Prose section / card / dialog headings -> 15-16 - Empty-state and dialog body copy -> 14-15 - Untouched: table cells & headers, MonoId, metric values/labels/units, chart labels, status badges, nav/topbar, chips, ports, kbd, buttons. 65 fontSize increases across 20 files. No data sizes changed; tsc + build green. * style(webui): centralize the type scale as rem tokens (fold in #249) Adopts #249's accessibility approach — a named rem `fs` scale in tokens.ts so the console honors the browser/OS font-size — on top of #250's role-aware sizing. The root is now 100% and every inline fontSize references an fs.* token, so operational data stays dense, prose reads larger, and the whole UI scales with the reader's font-size preference. - New `fs` rem scale: micro/label/meta/data/body/lead/strong/title/stat. - ~440 inline fontSize px literals -> fs tokens (value-preserving, so the approved hybrid sizing is unchanged); MonoId and chart labels included. - index.css root -> 100%, its font-sizes -> rem. Combines what #248 (flat px) and #249 (flat rem) each had half of. tsc + 218 frontend tests green. * ui: replace the never-useful latency heatmap with a command-latency panel (#245) * fix(ui): don't render a misleading latency heatmap on Splice 0.6.4 The Submit-to-commit heatmap buckets sequencing latency by the histogram's `le` boundaries. Stock Splice 0.6.4 exports that histogram with only the +Inf bucket, so every observation collapsed into the top (>2s) row — the panel read ">2s" for latency that is actually ~100ms, contradicting the average shown right above it. Same root cause as the hidden p50/p95/p99 strip. When no finite `le` bucket is present, show a short note explaining the density can't be resolved and pointing at the average, instead of the misleading grid. The grid returns automatically on Splice versions whose histograms carry finite buckets. The bucket-vs-note decision is extracted to a pure heatmapCellsOrNote() helper with a regression test. * fix(ui): make the heatmap "not available" note version-neutral Bringing up a Splice 0.6.9 LocalNet showed the note read "Not available on Splice 0.6.4" on a 0.6.9 instance — the +Inf-only histogram is the whole 0.6.x line, not 0.6.4 specifically (verified: 0.6.9 also exports a single-bucket histogram, histogram_quantile is NaN there too). Reword to "this Splice version" so it's correct on any affected instance. * ui: replace the latency heatmap with a command-latency panel The submit-to-commit heatmap never populates on any supported Splice version — 0.6.x exports the sequencing histogram with only the +Inf bucket (verified on 0.6.4 and 0.6.9), so a latency-density map has nothing to plot. Rather than leave a permanent "not available" note in that slot, put a metric there that is both important and actually live. Per Canton's observability guidance the documented golden signals (storage load, in-flight/dirty requests, node health) sit at zero on an idle LocalNet. The command-submission duration — Canton's documented command-latency signal — is a real average (sum/count) that populates and moves, and it restores a working latency view at the participant / ledger API layer (distinct from the sequencer-side "Sequencing latency" panel). Removes the heatmap machinery (loadHeatmap, heatmapCellsOrNote, the note), adds Q.cmdLatency through the existing per-node loader, and swaps the regression test to guard the query stays a real average, not a percentile.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #248 — base is that branch, so this diff shows only the rem change. Merge #248 first; GitHub will retarget this to
mainautomatically.Why
#248 put every Web UI size on the docs-site ramp — but as fixed px. The docs site is rem-based, so it honors a reader's browser/OS font-size preference (and the accessibility "large text" setting); the app ignored it. This closes that behavioral gap.
What
fsscale intokens.ts(rem):caption 0.6875rem·small 0.8125rem·body 1rem·h3 1.125rem·h2 1.375rem·h1 1.75rem— the same11·13·16·18·22·28ramp, now named and relative.fontSize(objectfontSize:and SVGfontSize={}) now referencesfs.*— no more magic numbers.index.cssroot flips16px → 100%— this is what actually enables scaling: rem now tracks the browser default.MonoId.sizebecomes astringdefaulting tofs.small; callers updated.Behavior
Verified live: setting the document root to 22px scaled every surface (wordmark, sidebar, headings, body, buttons) proportionally — a px UI wouldn't move.
Not fluid-with-viewport
This makes type user-scalable (respects the reader's preference), not viewport-fluid (
clamp/vw). Fluid-to-width isn't wanted for a dense data dashboard — it reflows tables as you resize. This is the right kind of responsiveness for this UI.Verification
tsc --noEmitclean ·vitest218/218 · rendered in both themes.