# Application Chrome

> Application Chrome: anatomy, keyboard behavior, state, and theming in Askr.

Source: [https://askrjs.com/docs/components/application-chrome](https://askrjs.com/docs/components/application-chrome)

Status: stable. Packages: @askrjs/themes.

**Published packages are authoritative.** Examples may lag behind a published contract. When guidance differs, verify the exports and TypeScript declarations in your installed package, then file an issue.

## Example

```tsx
import { Header, Main, Sidebar, SidebarContent, SidebarGroup, SidebarGroupLabel } from '@askrjs/themes/components';

<>
  <Header>Workspace</Header>
  <Sidebar><SidebarContent><SidebarGroup><SidebarGroupLabel>Projects</SidebarGroupLabel></SidebarGroup></SidebarContent></Sidebar>
  <Main><ProjectRoutes /></Main>
</>
```

## Purpose

`@askrjs/themes` and `@askrjs/ui` don't ship an `application-chrome` component, so treat this page as a walkthrough of how to assemble a full app shell from pieces that already exist. The outer frame comes from `Shell`, `ShellNav`, and `ShellMain`; the major regions are built with `Header`, `Main`, `Aside`, and `Footer` (plus its `FooterSection`, `FooterLinks`, and `FooterLink` parts). Fill the navigation areas inside that frame with `Navbar`, `Sidebar`, `Breadcrumb`, and `Pagination`.

## Install and import

```tsx
import { Shell, ShellNav, ShellMain } from '@askrjs/themes/components';
import { Header } from '@askrjs/themes/components';
import { Main } from '@askrjs/themes/components';
import { Aside } from '@askrjs/themes/components';
import { Footer, FooterSection, FooterLinks, FooterLink } from '@askrjs/themes/components';
```
There's no single "chrome" subpath — pull the pieces you need from the general components barrel and compose them yourself.

## Live examples

The example composes the persistent frame around routed content: brand, primary navigation, and the actions that stay put while the page beneath them changes. Keep the chrome in a layout component registered on a route group rather than repeating it per page, so navigating within the group replaces only the routed region.

## Anatomy

`Shell` is a layout alias (a flex container with no default direction), `ShellNav` is the same alias for a nav-shaped region, and `ShellMain` defaults to rendering as `<main>` with `grow` set so it fills remaining space. Around that, `Header`, `Main`, and `Aside` are semantic region wrappers, and `Footer` composes with `FooterSection`, `FooterTitle`, `FooterDescription`, `FooterLinks`, and `FooterLink` for a structured site footer. None of these enforce a particular arrangement — you decide whether nav sits above, beside, or inside the shell.

## State model

These are pure layout components; none of them own state. Anything dynamic in your chrome — a collapsed sidebar, an open mobile nav, the active breadcrumb trail — is state you manage in your own app and pass down as props or conditional children, the same way you would with `Navbar`'s `collapseAt` or `Sidebar`'s open/closed props on those individual component pages.

## Keyboard and accessibility

Because `Header`, `Main`, `Aside`, and `Footer` map to real HTML5 landmark elements, screen reader users get a sensible landmark structure for free as long as you don't nest them in ways that break that semantics (for example, don't put more than one unlabeled `<main>` on a page). Beyond that base, the chrome components add no keyboard behavior of their own — any focus management for things like a mobile nav toggle needs to come from whatever interactive primitive you compose them with.

## Styling and tokens

Each region component carries its own `data-slot` and default class from the underlying `Block` layout primitive, so you can target `header`, `main`, `aside`, and `footer` slots directly in CSS. Because `Shell`/`ShellNav`/`ShellMain` are thin aliases over `Block`, they also accept `Block`'s layout props (`gap`, `padding`, `direction`, etc.) for adjusting spacing without writing custom CSS.

## API

There's no unified "chrome" prop surface to document — each piece keeps its own component's props (`HeaderProps`, `MainProps`, `AsideProps`, `FooterProps`, plus the `Block`-derived layout props on `Shell`/`ShellNav`/`ShellMain`). Check each component's own page for its specific prop list rather than expecting a shared API here.

## Edge cases

Because chrome is assembled from independent pieces, the easiest mistake is duplicating landmarks — for instance rendering `Main` inside `ShellMain` when you only need one, or using `Aside` for both a sidebar and unrelated supplementary content without distinguishing them with labels. Responsive collapse behavior (mobile nav, collapsible sidebar) has to be composed explicitly from `Navbar`'s `collapseAt` and `Sidebar`'s own props; the shell components themselves have no breakpoint logic.

## Related pages

See Sidebar, Menubar, and Navbar and Navigation Menu for the navigation pieces that typically live inside this shell, and Layout Primitives for the broader page-layout primitives (`Block`, `Container`, `Text`) that chrome usually wraps.

## Documentation navigation

[Previous](https://askrjs.com/docs/components/breadcrumb-and-pagination/index.md) | [Next](https://askrjs.com/docs/components/table/index.md)