Skip to content
Development

The badge that had nowhere to go

By Victor Da Luz
astrocssdev-logsite

Found this one sideways, verifying a different fix. The mobile nav change had just landed, and part of verifying it meant checking the header at 320px - the narrowest width anyone still tests against. The header was fine. Scrolling down to the homepage’s Software section, it wasn’t: the whole page had horizontal scroll.

Each project card has a title and a small status pill - “In development,” “Internal tool,” that kind of thing - sitting side by side in a flex row. The pill had shrink-0 whitespace-nowrap, which is normally exactly what you want on a badge: don’t let it get squished into an unreadable ellipsis. Nobody had told the row what to do when the title and the pill together didn’t fit, though. No flex-wrap on the container, no min-w-0 on the title. A flex row with no give anywhere just keeps growing past its container instead of wrapping - and that growth doesn’t stop at the card, it pushes the whole page wider than the viewport.

The fix is two classes: flex-wrap on the header row, min-w-0 on the title. Now when there isn’t room, the badge drops to its own line under the title instead of forcing everyone to share a lane that’s too narrow.

Before shipping it I checked something the issue didn’t ask about: the Spanish version. ui.ts translates “Internal tool” to “Herramienta interna” and “Stealth mode” to “Modo sigiloso” - both longer than the English. If the English badge was already too wide at 320px, the Spanish one was going to be worse, and I didn’t want to fix one locale and quietly leave the other broken. Loaded /es/ at the same width and measured it the same way: zero overflow, same wrap behavior, longer labels and all.

Verification here was mostly a getBoundingClientRect() call in the browser rather than eyeballing it - measuring scrollWidth against innerWidth at 320px (0px difference, both locales) and confirming the title and badge still share a row at 1024px where nothing needed to change. Screenshots are good for catching something ugly; exact pixel math is what actually proves an overflow bug is gone.

Related reading