Page Shell - National Design System

Each chrome region has its own reference: Head, Header, Hero, and Footer. This page covers what sits between them: nds-content-layout and the classes that shape it.

Two of these pages carry the same Home shape but are authored differently, and the difference matters when you read the source. This site's own home page leaves the header, hero and footer to its Jekyll layout, so its source file holds only the sections. The Home Page Template uses the shell layout instead, which renders the document and the scripts and nothing else, so the page composes its own header, hero, content layout and footer and the source reads as a complete page. Read the template when you want the whole shape in one file. Either way the built HTML under _site/ is what a project copies.

Every DGA template uses the content page shape with the side menu off. Contact Us, Content, Form, and Service add side info. The 404 template is the one exception: it ships its own centered wrapper with no content layout.

Side Menu

nds-wSideMenu on the layout creates a two-column grid on desktop and shows the aside.nds-sidemenu placed as its first child. Without the class, the layout hides any direct aside child, so the two always ship together. On mobile the grid collapses to one column and the menu becomes a compact control. Add nds-top to the aside to render it as a bar above the content instead of a column. The aside's own markup is on the Side Menu page.

Side Info

nds-wSideInfo goes on the layout, but the aside is not a layout child. It sits inside the content, in a section marked nds-sideinfo-section, beside the text it tracks. The aside's own markup is on the Side Info page, and the Content template ships the full arrangement.

Stripe Classes

Add nds-stripe to nds-main-content. Every second section then takes the --background-stripe color, and the first section keeps the page background.

Add nds-odd beside it to flip the parity. The first section takes the tint instead, then every second one after it. Use it when the page opens on a section that must stand apart from the hero above it. nds-odd does nothing on its own.

Both classes work with a side menu and at every screen width. Striping counts sections, not wrappers, so a merged or added section flips the parity of every section below it. The Section page covers what that means for stacked wrappers.

Skipped Sections

A section that paints its own background is skipped in both parities, so a stripe never fights a colored surface. The section still holds its place in the count, so the sections around it stay on the pattern.

The last-modified strip is the one section handled apart. It reads as part of the section above it, so it takes the opposite parity and always matches that section.

Card view never stripes, whichever classes you set. Each section paints as a raised card there, and a tint behind the card reads as a mistake.

Best Practices

• Start every page by copying the shell of a built page whose shape matches, then swap the content. A hand-assembled shell tends to lose the wrapper classes that carry width, centering, and background behavior
• Keep one nds-content-layout per page and put all page content inside nds-main-content, structured as sections. Never nest one content layout inside another
• An aside.nds-sidemenu shows only when the layout carries nds-wSideMenu. Without the class the layout hides any direct aside child, so a menu that does not appear usually means the class is missing
• Use the console shape for admin and back-office pages. nds-full-width on body is the single switch, and the hero moves inside nds-main-content so it sits beside the side menu
• nds-full-width sets one variable, --nds-content-MaxWidth, and only nds-* regions read it. Non-NDS pages in the same document are unaffected, so the class stays in the markup and needs no per-route toggle
• Card view keeps its gutters and card gaps under nds-full-width by design: the page widens around the cards without flattening them
• Use the minimal shape for sign in, OTP, and other focused flows. nds-middle centers the content in the viewport, and the footer is omitted
• Side info is content-level, not a layout column. Keep the aside inside its nds-sideinfo-section next to the text it tracks
• Text-heavy pages can flatten the page hero with nds-flat on the hero section. See Hero for the hero's own variants

Framework Wrappers

React, Vue, and Angular add elements the shell does not expect. The shell styles direct children, so one extra element in the wrong place breaks the layout. Two places matter.

The mount root. A framework mounts into an element inside body, such as <div id="root">. That element sits between body and the chrome. body is a vertical flex column, and main grows to fill the space left over. A mount root breaks that chain, so the footer sits in the middle of the page when the content is short. Give the mount root display: contents, or pass the same flex rules through it. Nothing else in the shell depends on that position: chrome width, content width, section width, striping, and the side menu are all unaffected.

Wrappers inside the layout. Return a fragment from a component, so the sections land where the shell expects them. A plain div inside nds-content-layout takes the side menu's grid column, and the page then collapses to the width of that column. A plain div inside nds-main-content sets no width of its own, so narrow content such as a sign-in form pulls away from the page edges. Sections set their own full width, which is why the wrapper is the part that breaks.

Modifier Classes

These classes change page layout, so they must be in the markup the browser paints first. A class added from JavaScript after the app mounts costs one frame at the wrong shape. On a server-rendered page, write the class in the template. In a client-routed app where the class depends on the route, set it with a synchronous inline script that is the first child of body, before the framework mounts. A mount effect runs too late.