TopNav

​

What it is

The site-level bar above the page frame’s own Header — the strip that would carry branding and account-level chrome across an entire product, as opposed to Header, which belongs to one page. In code this concept maps to AppBar, re-exported with exactly one Titan override.

​

Live example

None. No Storybook story exists for AppBar — verified against the live Storybook index — consistent with it having no .stories.js file in its own directory.

​

Exports

Props inherited from the underlying AppBarOwnProps, verified directly against the type definitions — hand-confirmed, no generator exists for this concept: None of these is decided by Titan. The one override touches only sticky positioning at a wide breakpoint; every other prop renders at whatever the underlying default is.

​

Vocabulary

“TopNav” and “Header” are not the same region. Views overview already draws this line for the page frame’s own Header — this page’s AppBar sits above that, at the site level, and the two are separate exports with no relationship in code.

​

Choose TopNav when

• The product needs one persistent, site-wide bar above every page — branding, global account controls, global search — rather than per-page header content.
• The bar’s job is site-level identity and account context, not a specific page’s title or actions. Those belong to the page frame’s own Header.

​

Choose something else when

​

Anatomy

Nothing in source assembles these into one composed bar — see Composition.

​

Variants, sizes, and states

AppBar accepts the full set of underlying props (position, color, elevation, square, enableColorOnDark) with no Titan-specific restriction on any of them — unlike, for example, Button, which themes exactly two sizes and leaves a third explicitly undecided. Here, nothing has a themed value to prefer at all; every combination renders at whatever the underlying default is. The one thing Titan does decide: a top margin of 10%, applied only above an 1800px viewport width, and only while position="sticky". Confirmed directly from AppBar.overrides.ts — the entire override is one media query, nothing else.

​

Edge and failure states

​

Tokens

Verified directly from AppBar.overrides.ts — no per-component token emitter exists yet for this concept, so this table is hand-confirmed rather than generated. That is the only token anywhere in this concept. No color, elevation, height, or spacing value used by AppBar otherwise comes from a Titan token.

​

Composition

No component in core composes the site header the design library depicts. Views overview already records, in its own words, that the design library’s page template draws site-level chrome as “a site header carrying the logo, the account selector, global search and the account menu” — and states plainly that this is “deliberately out of scope” for the page-frame documentation. This page is where that concept should live instead, and what exists to build it is only loose parts:

• AppBar — the positioned bar itself.
• Logo — a page-frame template export (“Brand mark in the header,” per the committed concept map), sized to a maximum width, with no wiring to AppBar.
• Menu — a generic dropdown surface that could serve as an account menu trigger, with nothing account-specific about it.
• Global search has no export at all. SearchBars exists only as a Storybook story file with no corresponding .tsx source — it demonstrates a composition, not a reusable component.

AppBar’s own utilization data shows nine standalone usages across eight applications (ai-model-management ×2, signals, report-management, demo-discovery-generation, demo-call-generation, dashboard-management, current-calls-viewer, blocked-numbers) — each presumably assembling its own bar by hand, with nothing confirming whether any of them matches the design library’s full composition.

​

Content

Nothing to document. No text content is specific to AppBar itself — whatever a consuming app puts inside it (a product name, an account label) is that app’s own content decision, with no Titan guidance recorded anywhere.

​

Accessibility

• AppBar’s default root element is a native <header> — confirmed directly from AppBarTypeMap’s defaultComponent of 'header'. A <header> that is not itself nested inside <article>, <aside>, <main>, <nav>, or <section> maps to the banner landmark automatically.
• This is worth contrasting with the page frame’s own Header, which renders a plain <Box> (a <div>) with no landmark role at all — Views overview already records this as something a builder has to add by hand. AppBar gets a landmark for free that the page-level Header does not.
• If both a landmark-bearing AppBar and a manually-landmarked page Header appear on the same page, check that only one carries banner — two banner landmarks on one page is confusing for a screen-reader user navigating by landmark.
• No accessible-name guidance is recorded for the bar itself, and none of the composed pieces (logo, account menu, search) that a real site header would need are specified anywhere in this system today.

​

Constraints

​

Known issues

​

Why it works this way

AppBar is positioning, not a decision. It gives a consuming application a themed-adjacent place to put a top bar without deciding what goes inside it — which is defensible as a starting point, but it means the concept a reader means by “TopNav” (a composed site header with identity and account chrome) has never actually been built as a Titan export. The one override that exists — a sticky margin at a specific wide breakpoint — reads like a fix for one application’s problem that never generalized into a design decision.

​

Status

Hand-confirmed — no per-component status emitter exists yet for this concept.

​

Related

• Views overview — the page frame’s own Header, and the site-level chrome its own Note scopes out
• SideNav — the sibling question for the side of the screen
• Tabs — for sections of one page, not site-level chrome