About three years ago I had a client project where the designer wanted a hero headline that hit the container edges perfectly on every device. No gaps. I reached for old reliable FitText.js, and then the client picked a variable font the library’s resizing logic could not handle. So I wrote a custom ResizeObserver script that calculated the font-size from the scroll width. It worked. It was also 60 lines of JavaScript for one heading, which felt clever at the time and was really a debt bomb on a slow fuse.
My first idea was to hack it with CSS transforms: scaleX() driven by viewport units. It looked fine on my 5K monitor. The second I opened it on a tablet the aspect ratio went sideways and the text looked like it had been through a trash compactor. The fix had to be native, which is why the new CSS fit text properties are such a relief if you have ever fought this.
Native text-grow instead of FitText.js
A recent update over at CSS-Tricks covers it: Chrome Canary has started prototyping text-grow and text-shrink. That finally gets us away from magic numbers. You tell the browser to work out the available space and make the text fit, and it does.
The syntax is short. If you build WordPress themes you can drop this on your heading blocks with no external dependency at all, and it sits happily beside other recent layout work like native CSS masonry layouts or a complicated grid.
/* Using the new bbioon-hero-text utility */
.bbioon-hero-text {
/* Grow lines shorter than the container */
text-grow: per-line scale;
/* Shrink lines that overflow */
text-shrink: per-line font-size;
/* Optional: Set a cap so it doesn't get ridiculous */
max-font-size: 120px;
}The per-line value does the real work here: it treats every line on its own. The scale method stretches the glyphs, which suits some display fonts, while the font-size method changes the actual size of the characters. Either one holds up better than the vw hacks we have leaned on for years. Roma Komarov’s explainer walks through the logic in full.
The accessibility catch
Accessibility is where this gets awkward. If someone enlarges the font in their browser settings, a rigid fit-to-width rule can override that preference, and browsers are still working out how to handle the conflict gracefully. It is the same problem as native scroll-based animations: the feature is powerful, and you still have to use it responsibly. The MDN docs for text-size-adjust cover how text scaling normally behaves.
This gets complicated fast once you mix it with variable fonts and fluid typography. If you are tired of debugging someone else’s messy CSS hacks and you just want the site to work in every browser, drop me a line. I have probably seen it, and fixed it, before.
What to do with this now
- Prefer native over JavaScript and reach for properties like
text-growonce support lands, which keeps your bundle small. - Match the method to the job:
scalefor artistic display text,font-sizefor anything people actually have to read. - Keep a fallback while this is still experimental in Canary, so browsers without support get a sensible
font-size.
