Every documentation set is assembled from the same parts. A layout decides how those parts are arranged on the page — not which of them exist, and not what color anything is. There are three, they ship with the product, and the choice is one dropdown.
What every layout shares
Whichever you pick, a documentation page is built from the same shell:
- a header carrying your logo, the top navigation, the search control and an optional call-to-action button;
- the left sidebar holding the set’s navigation, with its filter box above the tree;
- the content column — breadcrumbs, the page title, the body, then previous/next;
- the on-page table of contents, built from the page’s
##and###headings; - a mini-bar that appears below the large breakpoint, standing in for the two rails with a sidebar toggle and a “Jump to” menu;
- the footer, and a search modal bound to Ctrl + K.
None of that is optional per layout. What changes is where each piece sits, how the page scrolls, and how heavy the previous/next controls look.
The three layouts
- Alpha
- Bravo
- Charlie
The default, and the most conventional. The header puts the logo on the left, the search box in the center and the call-to-action on the right, with the top navigation on its own row underneath. Everything below sits in one centered container capped at 1408px, and the whole page — sidebar, content and table of contents together — scrolls as a single surface.
Previous/next are understated: unboxed text links carrying the neighboring page’s own name, with no “Previous” and “Next” wording. The footer sits inside the content column, below those links, with the footer logo suppressed.
An application frame. The header is compact — logo on the left, then navigation, search and the call-to-action grouped together on the right of the same row. Behind everything sits a fixed, faintly tinted backdrop; the content panel is pinned to the viewport height and scrolls independently of the page, so the header never moves and the sidebar and content each have their own scroll.
Previous/next render as full-width bordered cards labeled Previous and Next. The footer sits at the bottom of the content wrapper, inside the scrolling panel, and keeps its logo.
Full width. The header spans the whole viewport rather than a centered column, and the sidebar sits flush against the left edge. The content column and the table of contents are centered as a pair within a 5xl-wide block, so the reading measure stays comfortable on a wide screen without the page itself being boxed in.
Previous/next are bordered cards labeled Previous and Next. The footer is the distinguishing part: it renders at page level, in its own band with a top border and its own ground, spanning the full width beneath everything else.
How to choose
The three are close enough that taste decides plenty of it, but four conditions push clearly one way:
How deep your navigation goes. Bravo’s independently scrolling panel keeps a long sidebar usable — you can scroll the tree without moving the page. Alpha’s single scrolling surface is easier to follow when the tree is short.
Whether you have a header call-to-action. Alpha and Charlie give the button its own space on the right of a spacious header row. Bravo packs navigation, search and the button onto one line, which is tight once the navigation has more than a handful of items.
Whether the documentation sits inside a wider site. If your docs share a header with a marketing site, Charlie is the one built for it: a full-width header reads as the site’s header rather than as a docs-specific bar, and it sits correctly over a flush-left sidebar. Alpha’s centered cap will visibly disagree with a full-width site header.
How long your pages are. Charlie’s centered content-plus-contents pair holds a comfortable measure however wide the window gets, which matters most when readers scroll for a long time.
These pages are the worked example: Leed’s own documentation runs on Charlie, because it lives inside the wider leed.ai site and reuses that site’s header, which needs to run edge to edge above a flush-left sidebar.
The three compared
| Layout | Stored value | Header | Content container | Previous / next | Footer |
|---|---|---|---|---|---|
| Alpha | alpha (the default) | Logo, centered search and CTA on one row; navigation on a second row | One centered container capped at 1408px; the whole page scrolls together | Unboxed text links carrying the neighboring page’s name | Inside the content column, logo suppressed |
| Bravo | bravo | Compact: logo left, navigation, search and CTA grouped right on one row | A panel pinned to the viewport height over a fixed tinted backdrop; scrolls independently | Bordered cards labeled Previous and Next | At the foot of the content wrapper, inside the scrolling panel |
| Charlie | charlie | Full width, spanning the viewport | Content and table of contents centered together at 5xl; sidebar flush left | Bordered cards labeled Previous and Next | Its own full-width band at page level, with a top border |
The one structural difference: Charlie’s footer
Alpha and Bravo render the footer inside the content column. Charlie renders it at page level, outside the header scope, in its own wrapper — which is why it can span the full width and carry its own ground and border while the other two cannot.
That distinction matters the moment you write CSS for the footer: under Charlie you are styling a page-level band, and under the other two an element inside the article column. The selectors themselves belong to the styling side of the product — How Styling Works explains which half of the CSS is Leed’s and which half is yours, and the docs shell partials are documented at Documentation Shell Partials.
Where you set it
The layout is a field of the documentation set’s own configuration. Open Settings → Page Types, expand the set, and pick from the Layout select under Configuration Overrides.
The same three options appear in Settings → General, in the Documentation section, as your company-wide default. Setting the default there saves you choosing again for every new set — that is what Default Content Configuration is for. The value that actually reaches your published site is the one on the page type, so a set with no layout of its own does not render; Creating a Documentation Set covers that trap along with the other four values a set will not render without.
Color, typography and code highlighting are separate choices from the layout and change nothing about the arrangement described here — they are all on Themes, Fonts and Code Themes.
What the layout puts on the page
Every documentation page’s root element carries a class naming its layout — docs-layout-alpha, docs-layout-bravo, docs-layout-charlie — alongside the classes for the font, the color theme and the code theme. Layout is the one of the four stored without its prefix; the builder adds docs-layout- when it writes the class.
That class is the hook for anything you write yourself. Scoping a rule to .docs-layout-charlie keeps it from firing if you ever switch, and is how the three layout stylesheets Leed ships stay out of each other’s way.