08 / Components

One page each, and the arguments that span them

Forty-two components, each with its own page: the component rendered from the package, then its spec in full. This page is the map, and the few arguments that are about more than one of them.

Three levels, and what each one owes the reader

Height is not decoration here: it says what a reader has to do to get rid of something. The base level is the page. The floating levelPopover, Menu, Tooltip — sits on one shadow and dismisses on a click outside. What separates those three is what each may contain and where the focus indicator has to be drawn.

The overlay level dims the page, traps focus and dismisses on Escape. That combination is the definition: anything that does not need all three belongs on the floating level instead. Dialog is that level, and a sheet is the same component anchored to an edge — for content that is long rather than urgent. AlertDialog goes one further: it announces on open and lands focus on Cancel, because a decision that size should not be one Enter away.

Composite widgets cost one Tab

Most components are a single control. The composite patterns own a region of the keyboard instead — Toolbar, Menubar, Tree, DataGrid, Treegrid, Listbox and Combobox. Their shared rule is that the whole widget costs one Tab and arrow keys move inside it. A row of buttons in a plain div is not a toolbar, however much it looks like one.

The builder surface is composed, not invented

The product’s main screen adds nothing to the system: a sections panel, a canvas and an inspector, built from buttons, fields, choice controls and rows, on the Sidebar layout primitive. The section rows reuse the menu item’s geometry, the inspector is Field and Choice at the small control height, and the canvas blocks are the list row with a border.

The shell is a query container, so the inspector leaves at the shell’s own width rather than the window’s — which is what lets the same builder sit in a full page, a preview pane and a docs example without three sets of rules. If a screen this central needs something new, the something belongs in the system first. That is the test the whole library was built toward.

Where this leaves off

Every component here is built, audited against 448 APG requirements, and covered by the browser suite and 299 assertions ported from W3C’s own tests. Each page below carries the component rendered from the package and its spec in full — the same eleven sections, generated from the same file the package ships.

What no test supplies: nobody has yet listened to any of this with a screen reader. Every spec says so in its own Accessibility section rather than claiming otherwise, and several of the fixes already made are specifically about what gets announced.

Every component, and where to find it

core

data

disclosure

feedback

forms

navigation

overlays

page

selection

structure

surfaces