Screen header
Generated from DESIGN_SYSTEM.md
Rules
Abstracted from Apple's navigation bar (iOS HIG; the same zones as a macOS window toolbar): leading = where you came from, center = where you are, trailing = what you can do here.
| Zone | Mobile top bar (setMobileHeader → MobileTopNavView) | Desktop content header (sidebar present, no top bar) |
|---|---|---|
| Leading | Below a domain root: back chevron to the parent. On a domain root: the sidebar menu. | Below a domain root: <PageBackLink>. On a domain root: nothing. |
| Center | The screen's title | Domain root: a large title (page-title) left-aligned. Deeper: the item's name as the title. |
| Trailing | The primary action as an icon (create = "+"), at most two | The same action as a page-level md button (btn btn-tinted btn-md, see Buttons) or an icon button |
- A domain root has no back affordance — the sidebar or tab bar is its "up". A root that links "back" to another product is a bug, not a shortcut.
- Create is the trailing "+", never a filled, shadowed button that outweighs the content it adds to. An empty list promotes create to its centered primary button ("Create your first X"). A grid of the user's own items may use a leading "+" tile instead (the home Hub card) — one or the other per surface, never both.
- "⋯" only for two or more secondary actions. A one-item overflow menu adds a tap and hides the only action; put that action in the zone directly.
- One header per screen. On mobile the top bar carries the title, so the content column does not repeat it.
- Button sizes in the trailing zone follow the button system's size scale; the two rules are kept in step.
Live specimens
Weekend market notes
Weekend market notes