Another release with nothing in the shipped files — it is all documentation. I used to feel faintly embarrassed writing those up, then I noticed that the pages people get stuck on are the ones where they cannot try the thing they are reading about. Four new panels you can poke:
- A live breakpoint readout on the responsive page — five chips, one lit, with a sentence on what that breakpoint changes. Resizing the window is the demonstration.
- A button class builder: pick a variant, a size and full width, and the class string assembles beside the result. Fifteen real buttons with one revealed, rather than one element restyled to imitate the others.
- A layout primitives explorer for stack, cluster, grid, split and shell, with a gap control that changes the tokens all five read.
- A markup reveal under five components, so the HTML that produced each one is a toggle away.
None of it uses JavaScript. Every panel is radio inputs or checkboxes and a :has()
selector, which is also the best demonstration of what modern CSS can do without help.
Update: two of them never worked
There is a punchline to a post about interactive documentation. The module picker and the script builder — the two most interactive things on the site — did not work at all, on any page, from the day they shipped until this week.
Their markup was fine. Their :has() rules were fine. Those rules live in
site.css, and neither page linked it. Nine blog posts and the examples index had the
same gap, which is also why the code blocks in those posts had lost their horizontal scrolling.
Every check passed the whole time: the HTML validated, the checker confirmed the controls existed
and were labelled, and the jsdom tests exercised the optional script, which is not what drives
these panels.
What none of that could see is whether the CSS that makes a control do something was loaded on
the page containing the control. A rendering engine sees it immediately — the panel simply does
not change. The lesson we took is narrower than "test in a browser": a static check can verify
that a thing exists and still tell you nothing about whether it is connected. The checker now
fails the build if a page uses a class that only site.css defines without loading
it, which is the connection it could not previously see.
What this post does not cover
- JavaScript-driven documentation tooling. Everything here is markup and CSS.
- Analytics on whether the panels are used, which we do not have per-panel.
Checked against checkboxes. Figures are measured from the build they describe.
What this doesn’t cover
These panels are documentation, not a playground: they change one property at a time against fixed markup, so you cannot type your own HTML into them. That was deliberate after the sandbox came out. They also need the site stylesheet, which is exactly the dependency that bit us later.
Sources: MDN on :has(). Every panel described here is live on the documentation pages linked above — the descriptions are of the shipped markup, not a mock-up.