root
Components that are already HTML.
Every one is a real <button>, <table> or
<details> that has been taught to behave - so it works in any framework or in none, the
platform keeps doing the parts it already does well, and there is nothing to install but the components you
use.
21
of 54 components, published to npm and covered by the accessibility gate
33
on the site with a warning, so the work can be reviewed before it ships
v0.0.1
one package per component, each released on its own
54
21 flagged Ready for Dev, 33 still in progress
10
Generated from the token stylesheets themselves
451
Plus 1471 declared by components
201
One icon font, addressed by name
0
Counted, not claimed: elements and attributes only
0
The platform is the dependency
65
Run in a real browser, plus e2e and an axe gate on the built site
57
One per component, published on its own
The idea
Extend the platform, do not replace it
A <button is="root-button"> is a button. It submits forms, it is focusable, it fires
click on Enter and Space, screen readers already know what it is - and
none of that is code anyone here had to write, test or keep working. The same goes for
<details> holding a disclosure, <table> holding a data table,
<select> holding a picker. What a root component adds is the part the platform leaves
out: the skin, the state it should reflect, and the ARIA the pattern needs.
The cost of that choice is honesty about it. A customized built-in cannot be attached to an element after
the fact - is has to be there when the element is created - so this codebase creates its
elements through one helper that knows it, and the component tag is derived from the class name, which is
why the build never minifies component JavaScript: a minifier that renames a class renames every tag with
it.
Tokens are the design, CSS is how it is spent
Colour, type, spacing, radii, elevation, motion, focus and layers are declared once in
@root/foundations and consumed by every component through custom properties. A scheme change
is not a second stylesheet: the ramps mirror across light and dark on their own through
light-dark(), so a component names one token and gets the right value in both. The foundation
pages on this site are generated by reading those stylesheets, which is the only way a page documenting
451 tokens can be trusted a month later.
No classes
Components are styled through element selectors, [data-part] and state attributes -
0 class selectors in everything that ships, counted at build time by the same code that
printed the figure above. It is not an aesthetic rule: a class is a name two people have to agree on,
while [aria-selected="true"] is a fact the DOM already holds. Styles arrive as
adoptedStyleSheets in cascade layers, so a page can override a component without a
specificity contest.
The documentation cannot drift
Every component page on this site is that component's README.md, rendered. The
snippets are not screenshots or transcriptions: each one is inserted into the page twice, once per scheme,
and what you see rendered above a snippet is that exact markup running. A component whose README lies
about its own API shows the lie on this page, in both schemes, next to the code.
Unfinished work says so
33 of the 54 components are not finished, and all 54 are on this site. Hiding the unfinished ones would protect nobody - the person deciding whether a component is ready needs a page to look at and a URL to put in a ticket - so an unflagged component opens with a warning instead of being absent, and the same flag keeps it out of the npm release and out of the accessibility gate.
Accessibility is a gate, not a section
WCAG 2.2 AA, checked by axe against the built site on every push, plus per-component keyboard and focus
tests. It runs on dist/ rather than on a dev server, so what is tested is the artefact that
deploys.