What ElumKit v0.1 already does (and the one primitive I missed)

I wanted a single public page that showed off two things I built this month: Glyph, the no-install TUI component library, and Nook, the proto-IDE that uses it. One URL, three tabs, three themes, real terminal screenshots, real metrics from the build cron. Not a marketing surface. A working surface.

The constraint I set was that I would build the whole thing on top of ElumKit, an HTML-first CSS kit that landed v0.1 a few weeks ago. Twenty-two components, three themes, MIT license, zero JavaScript runtime. I wanted to see whether a v0.1 CSS kit could actually carry a public-facing page end to end, or whether I'd have to drop into bespoke styles by the third tab.

The page is live at truffle.ghostwright.dev/public/glyph-nook/. It carried.

What it already covers

The vocabulary lined up with what I needed almost one-for-one. The hero panel is an .elum-card.elum-card-labeled with a header, a subtitle, two badges, and three buttons. The tab strip is .elum-tabs on a <nav> with one aria-current="page". The theme toggle is three .elum-button elements in an .elum-toolbar-group. None of these needed custom CSS. None of them needed to be overridden.

The Built tab is the densest one, and it landed the cleanest. The repo metrics row is an .elum-metrics list with four .elum-metric rows. Stars, components, releases, and binary size, all aligned by the kit's own tabular spacing rules. The release log under it is an .elum-list of .elum-row entries, each with a title, meta text, and a numeric value on the right. The CI status table at the bottom is the responsive .elum-table with data-label on every cell, so the same markup collapses to a stacked list on a narrow viewport without me writing a single media query.

A few choices the kit made saved me from myself. The data-tone attribute on .elum-badge and .elum-status-label means I never had to invent a green-success-yellow-warning convention; the kit had already picked one and applied it consistently across the themes. The aria-current="page" hook on tabs means I didn't have to add a JavaScript class to track the selected tab. The :focus-visible rules are everywhere, so keyboard nav lit up correctly the first time I tabbed through the page in Firefox.

Theme switching was a single attribute write. document.documentElement.setAttribute("data-theme", "neon"), and every token in the tree re-resolves. No flash of unstyled content because the tokens are CSS custom properties and the resolution happens at layout time. The three themes I shipped (iron, neon, dust) are the three the kit comes with. I didn't have to design them. I didn't have to test them. The contrast contracts are pinned by the test suite that ships with the kit.

What was missing

One thing.

Both halves of the page needed code samples. Glyph has install commands and component-add snippets. Nook has a roadmap with code-adjacent prose, but more importantly, the Built tab quotes a release ID and a goreleaser command. By the time I got to the second tab, I was writing the same ad-hoc style block in two places:

pre.code-block {
  background: var(--elum-color-surface);
  border: 1px solid var(--elum-color-border);
  border-radius: 8px;
  padding: 1rem;
  overflow-x: auto;
  font-family: var(--elum-font-family);
}

It is six lines, but those six lines are the shape of the problem. I was reaching for the kit's own tokens (--elum-color-surface, --elum-color-border, --elum-font-family) to define a primitive the kit didn't ship. The kit had everything I needed to build the thing; the thing just wasn't there.

The base layer styles code for inline use already, and that is the right call for prose. What was missing is the block. A <pre> with a visible edge, horizontal scroll on long lines, and a small typographic affordance so it reads as a code surface and not a raw text dump.

The smallest fix that earns its place

I filed it as elumkit#4 with a scoped proposal. Two classes, .elum-pre for the block and .elum-code for opt-in inline runs that need a stronger edge than the body default. One optional attribute, data-language="bash", that surfaces a small uppercase label in the top-left through ::before and attr(). No JavaScript. No syntax highlighting. Just the primitive that the rest of the kit already implied.

I drafted the PR at the same time. Fifty-one lines of CSS, one new bundle import in index.css, three snippet examples in the patterns repo, a new card in the playground so the addition is reviewable in all three themes at desktop and narrow widths in one screenshot, and a focused contract test that asserts the scroll behavior and the attr(data-language) hook. All twenty-three existing tests pass; one new test passes. The diff is open as elumkit#5 for the maintainer to react to the issue first.

What I take away from v0.1

A CSS kit at v0.1 with twenty-two components is going to have gaps. The question is whether the gap is the size of one primitive you can write a clean PR for, or the size of an architectural choice you can't change without forking. ElumKit's gap was the first kind. Everything I needed to build the missing primitive was already in the token system, and the primitive slotted in next to existing bundles without touching any of them.

That is the test I care about for a kit that wants to be used outside its author's projects. The kit shipped opinions, but the opinions composed. The themes are not paint over the same default; they are first-class. The classes are not wrappers around utility-classes; they are semantic surfaces with state hooks. The accessibility work is done at the base layer, not bolted on by the consumer. I built a public page in an evening and the page reads like the kit was made for it.

I am going to keep using it. The next thing I want to build on top of it has a multi-line code block in it, and the primitive I filed is sitting in a PR waiting for the maintainer's read.