See Views overview for the decided part of this page.
Known issues
Divergences are where code and design intent disagree; open decisions are where nothing has
been decided yet. Neither is resolvable by inference.
Gaps in the current rules
- Whether the header’s second row is truly exclusive (a tab bar or a filter row, never both)
needs confirming with the design team, not just read off a variant property. A variant
property is how the design tool models a fixed set of choices — a header that could hold
both would be built with two independent toggles instead, and which of those two structures
is right can be a modelling decision rather than a design one. What ships either way: the
frame has one
Controls region below the header, so a page can currently show both. The
page’s own constraint against this is the design’s apparent rule, and the question to ask
is whether a page with sections and header filters was ruled out or just never built.
- The frame’s regions don’t map to the expected landmarks — already recorded above.
- The tab-bar workaround costs structure, not just appearance.
Header puts every child
into one row, so Tabs passed as a child would land beside Left and Right rather than
beneath them — rendering it as a sibling instead reproduces the look but not the structure:
the header no longer owns its bottom edge, and the bar arrives with no gutter — already
recorded above.
- No archetype is fully documented. List view has its frame composition
written and nothing else; the other six pages are stubs. Which frame regions each archetype
requires, and what fills them, is undecided per archetype.
- No maximum content width. On a wide monitor nothing stops a full-width text body from
running far past a readable line length — already recorded above.
- When a page gets a
Footer is decided by Footers —
unit of commit, view vs container ownership, fixed vs static. Still open there: partial
validity under a view-level footer, what Cancel discards across several changed sections, and
where a fixed footer sits on a narrow or short viewport.
- A left-aligned footer variant has no stated use case.
justifyContent: "flex-start" pushes
every footer action left. Nothing says when a page should reach for it, and it conflicts with
the trailing-primary order stated elsewhere on this page.
- Pagination has no region. A paged list has nowhere in the frame to put its controls, and
three unreconciled implementations exist — already recorded above.
- No step indicator exists. A multi-step flow can offer a backward action but has no way to
show which step you are on or how many remain — already recorded above.
- When the leading slot applies is stated here and nowhere upstream. “A step in a sequence”
is this page’s proposal.
- No maximum number of tabs. The design library’s tab component publishes slots for nine, and
the page templates show five. Neither is a stated limit, and nothing says at what count a bar
should have been a side rail or a set of pages.
- Whether a tab bar and
Controls may both appear is settled in design and not in code. The
page templates show a tabbed table with a filter row and a search field beneath the header, which
is the order documented above. What the templates do not settle is whether those filters belong
to the page or to the table — in the template they are drawn inside the data grid, not in a page
region.
- Sub-tabs have a themed appearance and no rule. The rail’s indented mode exists in the theme,
so a nested level is buildable. Nothing states when nesting is right, or how deep it may go.
- Tab addressability is stated here and nowhere upstream. Two approaches ship side by side —
a bar of links, and a bar driven by local state with
TabPanel. The page’s own constraint
picks the first; that pick has not been signed off.
Information has no content rule. It is a growth slot with no stated limit, which is how a
header accumulates a paragraph.
- The site header is out of scope and undocumented. The frame stops at the page. What sits
above it, and how a page coexists with it, is not covered anywhere. The boundary matters in one
direction:
Contents sizes itself by measuring the site header at runtime, so a page frame
dropped into a shell that does not identify itself gets the wrong height — already recorded
above.
Constraints Titan should enforce
These are real, currently-true rules. Nothing in code stops a builder from violating them today — each is a placeholder for a guardrail Titan hasn’t built, not a decision still being made.
Last modified on September 17, 2026