Why a shared shell mattered

Part 4 of Homework 4 stresses consistency: the light/dark theme toggle must be visible, and the View Transition API should be easy to trigger. The simplest way to guarantee that was to extract the header into a single HTML snippet (header.site-shell). Each page now imports that snippet, so the document order, aria labels, and data-nav-transition attributes stay identical.

• Sticky, blurred header: A translucent backdrop keeps navigation present without hiding content. The header owns the theme toggle button, which exposes aria-pressed and announces the current mode.
• Noscript disclosure: Because the toggle and transitions lean on JavaScript, a <noscript> card warns users about reduced enhancements.
• Semantic links: Skip-to-content and contact shortcuts are first in the tab order, making the form-focused homework rubric happy.

Impact on deliverables

1. Part 1 (form-no-js) inherits the exact styling system from the landing page, which means labels stack, output regions align, and httpbin instructions live inside the same components.
2. Part 2 and 3 (form-with-js) benefit from the same shell, so new validation states do not cause layout shift.
3. Part 4 requires us to document where to find the theme toggle and the View Transition trigger. Because of the shared shell, screenshots from any page satisfy that requirement.

Reuse wins

By shipping one header, one footer, and one typography scale, I spend more time on meaningful content (forms and experiments) and less time fighting CSS drift. That decision sets the tone for this Astro blog—components first, repetition last. Up next: stress-testing the form workflow.*** End Patch