Footer relies on parent's bottom padding — implicit contract

[yigitdot]

Background

Since #125, components/site/Footer.tsx has no top padding (pt-16 was removed to fix #123 — the footer's own top padding stacked on top of the preceding section's --frame-pad-y and produced a conspicuous empty band).

This means the footer now derives all of its vertical separation from the bottom padding of whatever block precedes it. Today that is always a Frame (components/ui/Frame.tsx), which applies py-[var(--frame-pad-y)] (clamp 5–7rem):

• / — last section is Close (a Frame)
• /blog, /blog/[slug] — content wrapped in a Frame

So it works correctly on every current route, and the coupling to Frame's vertical rhythm is intentional (the design system has Frame own section spacing — see AGENTS.md).

Risk

The contract — "<Footer /> must be preceded by a block that supplies bottom padding (a Frame)" — is implicit and unenforced. Any future page that renders <Footer /> directly after a non-Frame block (or a Frame with fill={false} and unusually short content, or raw markup) will render the footer rule flush against the preceding content, with no diagnostic.

Options to consider

• (a) Give Footer a small intrinsic top padding (e.g. pt-10) and instead reduce the preceding section's contribution, so the footer is self-sufficient. (Trade-off: reintroduces some double-padding on Frame-preceded routes — the exact thing Unnecessary empty space above the footer on the homepage #123/fix: footer gap (#123) + scrollToAnchor NaN guard (#124) #125 removed; would need the preceding --frame-pad-y accounted for.)
• (b) Document and/or enforce the "footer must follow a Frame" rule — e.g. a comment on Footer, or composing the footer inside the final Frame / a shared layout primitive so the spacing is structural rather than incidental.

Not urgent — no current route is broken. Filing so the implicit contract is tracked rather than rediscovered the hard way when a new page is added.

Surfaced during the #125 review (PR #125).

[github-actions]

🎯 Agentic Issue Triage

This is a design-system fragility issue — no current route is broken, but the Footer component silently depends on its preceding block supplying bottom padding. The risk materialises the moment a new page is added without a Frame as its last section.

📋 Summary & Context

• Root cause: pt-16 was removed from Footer in fix: footer gap (#123) + scrollToAnchor NaN guard (#124) #125 to fix double-padding (Unnecessary empty space above the footer on the homepage #123). That fix was correct, but left an undocumented invariant: <Footer> must always follow a <Frame> (or any block that contributes pb ≥ ~5rem).
• Blast radius today: zero — /, /blog, /blog/[slug] all end with a Frame.
• Blast radius tomorrow: any new route that doesn't end with a Frame will flush the footer rule against content with no visual warning.
• Type: implicit contract / fragile coupling, not a regression.

⚖️ Options Analysis

Option	Pros	Cons
(a) Restore small intrinsic pt-* on Footer	Footer is self-sufficient	Re-introduces partial double-padding on Frame-preceded routes; needs --frame-pad-y accounted for
(b) Document the contract (comment + AGENTS.md)	Zero-risk, zero churn	Still implicit — a future dev may miss the comment
(c) Enforce structurally — compose Footer inside a shared layout wrapper or the final Frame	Impossible to misuse	More refactor; may conflict with the Frame→Footer compositional pattern
(d) Dev-time assertion — console.warn if Footer's previousElementSibling has no bottom padding in dev mode	Self-documenting, zero prod cost	Needs a useEffect; unconventional

Suggested path: Option (b) now (fast, no risk), with (c) considered when a non-Frame-terminated route is actually added.

✅ Checklist

• Add a JSDoc/inline comment to components/site/Footer.tsx documenting the "must follow a block that supplies bottom padding" contract
• Add a note to AGENTS.md under the design-system / spacing section (or Frame's entry if one exists)
• Decide between options (a)–(d) above; update this issue with the decision
• If option (a) is chosen: measure resulting gap on / and /blog to confirm it remains visually balanced, then adjust --frame-pad-y contribution if needed

🔗 Related issues & resources

• Unnecessary empty space above the footer on the homepage #123 — original "empty band above footer" bug that prompted pt-16 removal
• fix: footer gap (#123) + scrollToAnchor NaN guard (#124) #125 — the PR that removed pt-16 and created this contract
• components/ui/Frame.tsx — the component that currently supplies the padding
• components/site/Footer.tsx — where the contract should be documented
• [MDN: CSS padding inheritance]((developer.mozilla.org/redacted) — no gotchas, but a useful refresher on box-model separation

Generated by Agentic Triage for issue #127 · ● 2.3M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@c7d030cd6d4607b90d9ac3ffc8b24aff4f251632

[yigitdot]

Not needed for now — deferring this. The footer-spacing change was originally bundled in PR #129, which is being closed; the follow-up PR (#130) intentionally carries only the #128 renames and leaves the footer untouched.

No current route is broken (the implicit "footer follows a Frame" contract still holds everywhere today), so this stays open as a tracked, low-priority item to revisit when a non-Frame-terminated page is actually added.