Components

There is a working component library behind this system, and it is not a prototype. It renders the illustrated chapters, it renders every report the practice issues, and it renders the page you are reading. Headings, records, callouts, quotes, specimens, tables, status marks, navigation and the print layout are all built from it.

What has not been done is the part that makes a component library a component system. Each part needs its anatomy stated, its variants named, its states enumerated, and its accessibility requirements written where a developer will actually read them. Until that exists, the library is a set of working conventions rather than a specification, and a working convention only survives while the person who wrote it is still available.

What is already decided

Two things, and both are constraints rather than components.

First, a state is never carried by colour alone. Every status in this system has a readable label and a geometric mark, so it survives greyscale, a monochrome print, and a reader who cannot distinguish the hues. The three marks on this page are an example of that rule rather than a decoration.

Second, no component may invert its own ground. A surface changes theme through one route and one route only. When a component sets its own background the result has been measured at 2.25 to 1 for body text, which is well below every threshold the system holds itself to, and that is why the rule is absolute rather than advisory.

The one number that is missing

No minimum target size for an interactive element is specified anywhere in this system. That is a real gap rather than an oversight I am glossing over: the accessibility chapter's interaction section is outstanding, and there is no canonical figure to consume. Every button on this site therefore gets a comfortable hit area as a consequence of its type size rather than as a specification, and the moment a number is agreed it belongs in a component rule.