Width-aware truncation

[benjaminleonard]

This has long been on my list to fix. The char-based truncation we have currently leaves a lot of unused space and is unreliable. In part because character widths (plus kerning) vary so much between two strings of identical number of characters.

<Truncate> now fills its container and truncates based on actual rendered width.

• position="end" is pure CSS (text-overflow: ellipsis). JS only checks scrollWidth > clientWidth on hover to decide whether to show the full-text tooltip
• position="middle" measures with canvas measureText (accounts for kerning and letter-spacing) and searches for the longest string that fits

Also standardizes ID display: IDs now middle-truncate everywhere, and adds truncation + copy buttons to places that had none. FileInput gets contain: inline-size on its label, fixing a bug where it forces the input wider. I think this predates the truncation change.

Test changes to match.

From some local robot tests, the truncation measurements, including the binary-search are all very quick.

This also means we aren't truncating when there is space to display, before:

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
console	Ready	Preview	Aug 14, 2026 10:56am

[david-crespo]

I'm still seeing some truncation when there's space to spare. Looks awesome in motion, though.

2026-08-14-truncate-live.mp4

Probably not introduced here but I'm noticing that the ellipsis plays poorly with the dashes, I wonder if there's room to be clever or we just have to live with it.