feat(styles): make the cover section height configurable - #2108
Merged
Conversation
The height of a cover section was hardcoded in `_styles.scss` as `--section-height: 88vh` with `--max-section-height: 1024px`. Neither value was documented or reachable from a site's configuration, so a site wanting a genuinely full-screen hero had no supported way to get one -- `cover: true` always stopped at 88% of the viewport, and the 1024px cap shrank that share further on xxl and tall viewports. Expose both as `main.sectionHeight` and `main.maxSectionHeight`, plumbed through `head/stylesheet.html` alongside the existing navbar offsets. Defaults are unchanged, so no existing site shifts: the 88vh shortfall is deliberate, letting the next section peek above the fold. Verified in the exampleSite at 1900x1031 with a `cover: true` hero: defaults still place the hero bottom edge at 907px (88.0% of the viewport, reproducing the report); `sectionHeight = "100vh"` plus `maxSectionHeight = "100vh"` places it at 1031px (100.0%). Closes: #2107 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for gethinode-demo ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Collaborator
Author
|
🎉 This PR is included in version 3.16.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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
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.
Fixes #2107.
Analysis
cover: truewas working. A cover section is 88vh, not 100vh — the reporter's screenshot measures out to exactly that._styles.scss:62--section-height: 88vh_styles.scss:86main:has(section:first-of-type.section-cover) { margin-top: var(--overlay-offset) }_styles.scss:124.section-cover { min-height: calc(var(--section-height) - var(--overlay-offset)) }Total =
overlay-offset + (88vh − overlay-offset)= 88vh, independent of navbar height. Measuring the reported screenshot: viewport 1900×1031, hero/next-section boundary at y=907 → 87.97%.--max-section-height: 1024pxshrinks that share further fromxxlupwards and above 1400px tall.Not a regression —
git diff v3.14.1 HEADon that file shows only the unrelated.title-caseaddition, and88vhhas been there since 7f7c8d1 (2025-06-18).The 12vh shortfall is clearly deliberate: it lets the next section peek above the fold. The problem is that it was hardcoded, undocumented, and had no supported override, while three separate places promised "fullscreen".
Change
Expose
main.sectionHeightandmain.maxSectionHeight, plumbed throughhead/stylesheet.htmlalongside the existing navbar offsets. Defaults are unchanged — no existing site shifts.Verification
Built the exampleSite (Hugo 0.164.0, the reporter's version) with a
cover: truehero, measured in a real browser at their exact 1900×1031 viewport:sectionHeight/maxSectionHeight = "100vh"lint:stylesandtest:templatespass.The libsass path shares the same
$varsdict as the adjacent$overlay-offset, so nothing there is transpiler-specific beyond theh.bridge added to_variables-dart.scss. It could not be exercised end-to-end: libsass already fails in the exampleSite for unrelated pre-existing reasons (FontAwesome v7 requires DartSass;mod-blocks/preview.scss:58uses amin()libsass rejects).Related
coverflag into the hero body partialcoverargument description🤖 Generated with Claude Code