Nav Bar

Three sizes, one markup

Both are the same markup with different CSS, at one breakpoint, mutually exclusive on either side of it. Two components would be two things to keep in step, and the one only visible on a phone is the one that goes stale.

A 23rem drawer on a 390px phone is not a drawer. It is a panel with a 40px strip of unusable page beside it, and that strip is a "close" target nobody can hit. Full width also gives the rows the space they were designed at instead of squeezing them. The tablet keeps the drawer, because there a strip of page is wide enough to still read as page.

The drawer takes 420ms, slower than the desktop panel's 220ms. It travels the width of the screen, and a full-screen surface that arrives in 200ms reads as a page change rather than as something opening.

Four traps, all found the hard way

Closing it

While the drawer is open, the toggle becomes position: fixed above the sheet and the bars cross into an X.

That is deliberate rather than a second close button. The drawer covers the header the toggle lives in, so the toggle has to be lifted out or there is no exit at all - and lifting the same control is better than adding another, because the thing that closes the menu is visibly the thing that opened it, in the same place, having changed shape.

Escape also closes it, for free, because it is a <details>.

Nothing on the page moves as it opens, and getting there meant taking something out rather than adding it.

The obvious way to stop the page moving behind a drawer is html:has(.nav-burger[open]) { overflow: hidden }. It is worse than the problem it solves, twice over. Making the scrolling element non-scrollable drops its scroll offset, so opening the menu halfway down a page throws the reader back to the top and closing it does not bring them back. It also removes the scrollbar, which makes the document about fifteen pixels wider at that instant, so everything centred slides sideways as the menu arrives.

So there is no scroll lock. What actually needed fixing was scroll chaining, and that is handled where it happens: overscroll-behavior and touch-action on the sheet, and data-lenis-prevent so the smooth-scroll driver leaves the drawer alone. The page behind can still be scrolled while it is covered, which is a smaller cost than losing someone's place.

scrollbar-gutter: stable stays on html regardless, because the width of the gutter should not depend on whether a given page happens to be long enough to need it.

Inside the drawer, every row starts with a tile on one column, group headers included. Items sit behind a rule set in by the tile's width rather than indented: indenting would push each item's tile a few pixels right of its group's, and the drawer would read as two columns that nearly line up, which is worse than either lining up or clearly not. Rows are at least 44px tall, and they answer a press with :active, since a touch screen has no hover to give.

Where this is used

site-nav.tsx is nine lines and holds one decision: that this particular site has a wordmark and a GitHub link. Everything else moved out to somewhere it can be edited without touching a component.

The Markdown format

- [Components](/components) `layers`
  - {categories}
- [Writing](/posts) `note`

A top-level item is an entry. Indent under one and it becomes a panel; leave it alone and it stays a plain link, which is right for most of them - a menu that opens to reveal one link is more interface than the thing it hides.

The backticked word is a glyph name. pnpm doctor rejects one that is not in the glyph table, so a typo fails a check rather than silently rendering nothing.

{categories} expands from the registry, with a live count per category. Writing the categories out in the nav file would be a second list to keep in step with the first, and the first thing that goes wrong is a menu entry that filters to nothing.

The glass

Each icon sits on a tile with a light top edge fading into a darker fill. That gradient is the whole effect: a lit edge over a solid body is what reads as a raised piece of glass, and it costs one linear-gradient.

It used to have a backdrop-filter as well, which is what crashed the renderer. Removing it changed almost nothing about how the tile looks, which is the useful part of the story - the filter was never doing the work.

Hovering the row lifts the tile with it - the border warms to the accent and so does the glyph - so the whole item reads as one target rather than as a link with a picture next to it.