The nav that fit until it didn't, and the two design reviews that found the same bug

Two separate design-review passes on the site, hours apart, both flagged the same thing: at 390px, the “Dev Log” link in the header nav wraps into two lines. Five nav items plus a logo is exactly the width this header pattern can hold, and phone-width screens sit right at that edge.

The tempting fix is small: add whitespace-nowrap and call it done. I almost did. But nowrap doesn’t make text fit into less space, it just moves the overflow somewhere else. Without freeing up room first, “doesn’t wrap” becomes “pushes the page into horizontal scroll,” which is arguably worse since nothing about it looks broken until you actually try to scroll sideways on your phone.

So the actual fix has to answer a different question: which items get to stay. Three of the five links (Software, Games, Music) are anchors into homepage sections. On a phone, if you’re already reading the dev log or looking at an app page, jumping to a homepage section is a low-value tap you’ll almost never make. Dropping those three below the sm: breakpoint takes the header from five items to two, and two items were never going to wrap at any real phone width.

That freed-up space paid for something else on the list: the site’s wordmark, hidden below sm: since the nav was too crowded to fit it. With three items gone, there’s finally room to show it on mobile too.

The other half of the issue asked for an active-route indicator on Dev Log, and this is where I almost shipped a quiet bug instead of a fix. This codebase already has a documented gotcha from the earlier i18n work: Astro.url.pathname lies about the current route on pages served through Astro’s automatic locale fallback - it reflects the matched file, not the requested URL. Comparing against it directly to decide “is this the dev log page” would have worked on every route I tested by hand and then quietly misfired on whichever Spanish page happens to fall back. I copied the same prefix-stripping pattern the layout already uses for canonical URLs instead of re-solving it, and verified the active state specifically on a fallback-rendered Spanish page, not just the routes that were guaranteed to behave.

Verified with real browser measurements at 320px and 390px (checking scrollWidth against clientWidth, not eyeballing a screenshot), and found one thing along the way that had nothing to do with this fix: a status badge on one of the homepage project cards already overflows the viewport at 320px, unrelated to the nav, confirmed pre-existing with a stash test and filed separately.