Welcome to Vanilla Breeze
This bell pulls live notifications from /go/notify/messages — the same contract documented at /docs/concepts/service-contracts/. Static articles like this one are the no-JS / no-backend fallback.
data-page-layout
Body-level page-shape template with semantic-element grid identity. Drop on
and the semantic children (header, nav, main, aside, footer) auto-assign to grid areas — no classes, no wrappers, no.
Overview
The data-page-layout attribute on <body> turns the page into a CSS grid where semantic elements are the grid items — <header>, <nav>, <main>, <aside>, <footer> auto-register to named grid areas. No classes, no wrappers, no <div data-area="main"> — the existing semantic markup IS the layout.
This is the page-shape sibling of data-layout (which lays out the children of any element). The hierarchy:
data-page-layout— on<body>, owns the page structure.data-layout— on any element, lays out a single component.
Usage
HTML
<body data-page-layout="sidebar-left"> <header>...</header> <nav>...</nav> <main data-layout="stack"> <article>...</article> </main> <footer>...</footer></body>The semantic children land in the body-header, body-nav, body-main, body-footer grid areas automatically. A second <nav> (e.g. a secondary nav) goes to body-nav-secondary.
Layout values
| Value | Shape | Notes |
|---|---|---|
stack | Vertical: header / nav / main / aside / footer | Default for content-first sites. |
sidebar-left | Header / nav-on-left + main / footer | Docs sites, blogs. |
sidebar-right | Header / main + aside-on-right / footer | Articles with TOC. |
holy-grail | Header / nav-left + main + aside-right / footer | Classic three-column. |
app-shell | Sticky header + sidebar + scrolling main | Application chrome (gap: 0). |
dashboard | Sticky header + nav + main grid | Admin / data-heavy UIs (gap: 0). |
Semantic elements → grid areas
Default mapping (apply to direct children of the data-page-layout element):
| Element | Grid area |
|---|---|
<header> | body-header |
<nav> | body-nav |
<main> | body-main |
<aside> | body-aside |
<footer> | body-footer |
second <nav> | body-nav-secondary |
<nav class="bottom"> | auto (escape hatch — flows naturally) |
Container queries
Each major region also gets a CSS container-name so component CSS can adapt to the region it lives in:
<main>→container-name: region-main<nav>→container-name: region-nav<aside>→container-name: region-aside
CSS
/* A card knows it's in the main region vs the sidebar */@container region-aside (max-width: 16rem) { .product-card { /* compact variant */ }}Composition
data-layouton regions — nest a stack/grid/cluster inside<main>for the article body.data-layout-density— paircompactwithdashboard/app-shell.data-backdropon<html>— canvas backdrop renders behind the page-layout grid; the two compose cleanly.
Why a body-level attribute (not a custom element)
A page shell is not a wrapper — it's the page. Wrapping <body> contents in <page-shell> would break document semantics (header / nav / main / aside / footer are direct children of the body for a reason — landmark roles, default styling, AT navigation). The attribute form preserves the semantics and adds the grid behavior on top.