[BUG] Hero cover=true does not display in full screen

[giomf]

Describe the bug

Setting cover = true in hero block does not render the hero banner in full screen.

To reproduce

Steps to reproduce the behavior:

1. Set a background image as hero banner
2. Set cover = true
3. Rebuild
4. Hero banner does not renders in full screen

Alternatively, include the commands from your terminal as bash script.

Expected behavior

The hero banner should get displayed in full screen

Log file

Screenshots

Host environment

Please complete the following information where applicable.

• Hinode version: v3.14.1
• Host OS: nixos
• Node version: v24.11.0
• Browser: Mozilla Firefox 153.0.1

Hugo environment

Copy the output of hugo env or npm run env here.

hugo v0.164.0-ce2470e7012b5ab5fc4e10ebe4027e9f8d9e00dc+extended linux/amd64 BuildDate=2026-07-06T16:39:30Z VendorInfo=gohugoio
GOOS="linux"
GOARCH="amd64"
GOVERSION="go1.26.3"
github.com/webmproject/libwebp="v1.6.0"
github.com/sass/libsass="3.6.6"

Additional context

Add any other context about the problem here.

[markdumay]

Thanks for the detailed report — the screenshot made this diagnosable without a reproduction.

What's happening

cover: true is working. A cover section in Hinode is 88vh, not 100vh — and your screenshot measures out to exactly that:

viewport:                 1900 × 1031
navbar bottom:            y = 93
hero / next-section edge: y = 907   →  907 / 1031 = 87.97 %

The chain, all in assets/scss/common/_styles.scss:

Line	Rule
62	--section-height: 88vh
86	main:has(section:first-of-type.section-cover) { margin-top: var(--overlay-offset) }
124	.section-cover { min-height: calc(var(--section-height) - var(--overlay-offset)) }

Total = overlay-offset + (88vh − overlay-offset) = 88vh, independent of your navbar height. That the total lands on 88vh regardless of the offset is also what proves the class is applied and the CSS is present — a hero that had lost section-cover would be content-height with no top offset.

There's a second knob: --max-section-height: 1024px caps it from the xxl breakpoint upwards and on viewports taller than 1400px. At 1900×1031 the cap isn't binding, but on a 1440p display a cover hero lands at ~85% and the share keeps shrinking as the screen grows.

This isn't a v3.14.1 regression — 88vh has been there since 7f7c8d1 (June 2025).

So it's partly a real bug, just not where you looked

The 12vh shortfall is deliberate: it lets the top of the next section peek above the fold and invite scrolling. The actual defect is that this was hardcoded, undocumented, and had no supported override, while three separate places promised "fullscreen" — the hero docs ("full-page hero", "full-height hero") and the shared cover argument description ("rendered fullscreen"). Your expectation was entirely reasonable given what the docs say.

Investigating also turned up a genuine plumbing bug next to it: the hero block never forwarded cover into its body partial, so hero-image-full-height had never applied to a rendered page. It matters for portrait illustrations, which could inflate a cover hero past its intended height.

Fixes in flight

• feat(styles): make the cover section height configurable #2108 — adds main.sectionHeight and main.maxSectionHeight (defaults unchanged)
• fix(hero): forward the cover flag into the hero body partial mod-blocks#190 — forwards the cover flag into the hero body partial
• fix(hero): describe the real cover height instead of "full page" mod-docs#134 — corrects the "full-page hero" wording
• fix(arguments): correct the cover argument description mod-utils#360 — corrects the shared cover argument description
• gethinode/gethinode.com#189 — documents the new settings

Measured in the exampleSite at your exact viewport, with Hugo 0.164.0: defaults keep the hero bottom edge at 907px (88.0%, reproducing your screenshot); sectionHeight and maxSectionHeight set to 100vh put it at 1031px (100.0%).

Workaround right now

In your site's assets/scss/theme/theme.scss:

.main {
    --section-height: 100vh;
    --max-section-height: 100vh;  // otherwise the 1024px cap bites on tall / xxl screens
}

Setting only the first one will still leave you short on large displays — that's the part that's easy to miss.

[markdumay]

🎉 This issue has been resolved in version 3.16.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[markdumay]

All of this has now shipped. The bot above only mentions hinode v3.16.0, which is the settings half — the fix spans four releases:

Release	What it gives you
hinode v3.16.0	main.sectionHeight and main.maxSectionHeight
mod-blocks v2.3.5	the hero block now forwards cover into its body partial
mod-docs v1.15.7	hero docs no longer claim a "full-page" hero
mod-utils v6.8.5	the cover argument description no longer says "fullscreen"

Getting it

You're on v3.14.1, so:

npm run mod:update

That pulls hinode v3.16.0 and brings the other three along with it.

Then, for a genuinely full-screen hero

Drop the theme.scss workaround I posted earlier and use the settings instead, in config/_default/params.toml:

[main]
    sectionHeight = "100vh"
    maxSectionHeight = "100vh"

Both matter. maxSectionHeight caps the section at 1024px from the xxl breakpoint upwards, so on a display larger than yours the first setting alone would still leave you short. Defaults are unchanged (88vh / 1024px), so nothing shifts for anyone who doesn't opt in.

Verified at your exact 1900×1031 viewport: defaults put the hero bottom edge at 907px (88.0%, matching your screenshot); with both set to 100vh it lands at 1031px (100.0%).

One note on the mod-blocks change

While tracing this I found that the hero block had never forwarded cover into its body partial, so the "full height image" styling had never actually applied. That's fixed — but it does less than its name suggests, and I'd rather say so than let you expect a change that won't come. For a landscape or roughly square illustration it makes no visible difference: object-fit: contain means the width is already the limiting dimension. It only matters for a distinctly portrait illustration, which it now keeps inside its column instead of letting it stretch the hero past the cover height. Your emblem is close to square, so you probably won't see any difference from it.

Docs

Both pages are updated and live:

• Hero block — states the actual height and why it stops short of the viewport
• Layout configuration — the two new settings

Thanks again for the report. The screenshot was precise enough to diagnose from directly, and you were right that something was wrong — just in the documentation rather than the CSS.

[giomf]

Thanks for the quick fix and also for the detailed analysis.

The 12vh shortfall is deliberate: it lets the top of the next section peek above the fold and invite scrolling.

This is a valid point. What about adding an optional arrow-like-symbol at the bottom like we know from many other pages that indicates or invites to scroll down to see the rest of the page?

[markdumay]

This is a valid point. What about adding an optional arrow-like-symbol at the bottom like we know from many other pages that indicates or invites to scroll down to see the rest of the page?

That's certainly an option. This site shares some examples worth trying: https://freefrontend.com/css-scroll-buttons/.