- Job
- Chrome frame
- Requirement
- must specify
- States / rules
- Bar slots; overlay/rail host
- Specified means
- Shell ≠ canvas
- Hardest context
- Theme on shell only
[data-product-chrome]
Tokens on html
Baseline vs product decision
Building Blocks baseline supplies
- Landmark and focus-order guidance.
- A reusable shell composition that products can adapt.
- Responsive navigation patterns and overlay relationship.
- Theme inheritance across shell and product surfaces.
The consuming product still decides
- Actual information architecture and destination labels.
- Which utilities exist and who may use them.
- Breakpoints/interaction mode for rail vs overlay navigation.
- Product Catalog status and exceptions.
Anatomy
This is documentation anatomy, not a public API shape.
Defines persistent product chrome without swallowing product-local content.
Communicates location and destination consistently.
Provides a stable main landmark and responsive reading area.
Holds account/product utilities without becoming a second app.
Explicitly states what becomes drawer, rail, header, or hidden content.
Preview
Preview — not a published component API.
Product chrome frames the work.
Usage
Job: Chrome frame.
Shell ≠ canvas
When not to use
Do not let the shell become a feature dump. Product navigation and settings ownership remain product-local decisions.
Variants
The checklist row does not authorize this page to invent a final component API. Where the source rule names a variant, preserve it; otherwise keep the implemented variant set minimal and job-driven.
States & behavior
Bar slots; overlay/rail host
Default, Hover, Focus, Active/Pressed, and Disabled apply to interactive controls. Error, Loading, Empty, and Success apply where the component takes or reports data.
Hardest-context test
Building Blocks baseline recommendation: Exercise shell + overlay at 375px, keyboard navigation, long destination labels, and dark appearance without losing wayfinding.
Accessibility
- Use native semantics whenever they match the job.
- Keep keyboard focus visible and distinct from hover.
- Do not rely on color alone for state.
- Maintain touch-operable targets and no hover-only actions.
- For composite/overlay controls, document focus movement, Escape, and return focus as applicable.
Responsive behavior
Document sm/md/lg behavior explicitly: whether the component reflows, collapses, changes density, or stays structurally the same. Preserve touch targets and avoid hover-only behavior.
Theme comparison
The component job and interaction contract stay stable while product expression changes.
Product chrome frames the work.
Product chrome frames the work.
Product chrome frames the work.
Tokens
Bind the implementation to semantic roles for surface, text, border, focus, spacing, shape, and motion as needed. Actual token names must come from the implemented Foundation; this demo deliberately does not mint package-level token names.
Code / Storybook
When this component exists in code, this section should link to its source and Storybook stories for executable states, Controls, viewport, accessibility checks, and interaction tests. The documentation page remains responsible for job, guidance, source contract, product decisions, themes, and Catalog lineage.