Phase 5 item #4: root document fills + centers the viewport#10
Merged
Conversation
Before: at viewports wider than the design (or taller than its content), the rendered canvas left dead white strips on the sidebars and/or below the document, because the root's background lived on a div inside body and html had no fill of its own. Two changes to the renderer's outer scaffold: - Hoist `root.fill` / `root.gradient` to `<html>` (with `min-height: 100vh`) so any uncovered area shows the design's color instead of browser default white. Falls back to no html bg when the root has no fill. - Body gets `margin: 0 auto` so it centers horizontally when the viewport exceeds `max-width`. At viewport == design width (default screenshot path), this is a visual no-op. The hero PNG changes by ~58KB — the previously-visible white strip below the dashboard (where body's min-height exceeded the doc's content height) is now filled by the gradient. The byte change is the win, not a regression. `test-root-centering.ts` covers four cases (solid fill, gradient, no fill, no-overflow viewport) — 12/12 assertions pass. Existing fluid-widths and default-font smokes still pass.
This was referenced May 15, 2026
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.
Summary
Before: at viewports wider than the design width — or taller than the doc's content height — the rendered canvas leaked dead white onto the sidebars and/or below the document. The root's background lived on a
<div>inside<body>, and<html>had no fill of its own.Two changes to the outer scaffold:
root.fill/root.gradientto<html>(withmin-height: 100vh) so any pixel not covered by the document inherits the design's color instead of browser-default white. Falls back to no html bg when the root has no fill.body { margin: 0 auto }so body centers horizontally when the viewport exceedsmax-width. At viewport == design width (the default screenshot path), this is a visual no-op.Test plan
test-root-centering.ts— 4 cases × 3 assertions: solid fill / gradient / no fill / no-overflow viewport. 12/12 pass.test-fluid-widths.ts— 8/8 still pass (no regression on PR Phase 5 item #3: fluid widths (minWidth / maxWidth) #7).test-default-font.ts— both pass (no regression on PR Default text to a sans-serif stack at the renderer level #9).scripts/build-hero.tsreruns clean. The hero PNG changes (~+58KB). Previously a thin white strip showed below the dashboard (body'smin-height800 exceeded the doc's content height); it's now filled by the gradient. The byte change is the visible improvement.Why the html-background approach
Considered making
<body>itself span the viewport with the doc as an inner max-width wrapper — cleaner conceptually, but invasive. The html-bg hoist is one new helper (rootBackgroundCss) and one extra CSS rule; the document's own background draws on top at the design-width band, so visual fidelity inside the design is unchanged. The doc-div's own background is redundant within the design area but harmless.