Reimagining Fluid Typography
19 comments
·February 28, 2025chrismorgan
alwayslikethis
I wish there is a browser extension that would do the following:
Evaluate all the font sizes in viewable text, find the median (weighed by character count), set it to my preferred size, scale the rest accordingly.
This is akin to volume normalization for audio. Just like TV channels shouldn't increase their volume willy-nilly, neither should web developers get to scream their entire articles at me.
the_other
On the other hand, the site was one of the most comfortable to read, for me, on my phone, with my eyesight. I didn’t have to zoom + pan + scan as much as usual.
deredede
Do yourself a favor and go increase the text size (not zoom!) in your browser's (if not OS's) settings.
alt227
Fully agree. There seems to be a trend currently to write blogs about web based text in a terribly formatted web font.
EDIT: TBH the whole site is terrible on desktop. Everything is too big. I get the feeling this person is mobile focussed.
robertoandred
It’s terrible on mobile, too. Everything is big, plus a horizontal scroll.
jasonjmcghee
If you move the sliders outside of the resizable area, and swap from using the 'change' event to the 'input' event, you'll have a nice fluid interactive demo.
notpushkin
> Sites with smaller body text would ideally increase their font size, but sites with the same size or larger text certainly shouldn’t get even bigger.
Maybe something like this?
html { font-size: clamp(16px, 1.5em, 24px); }necovek
I think that's in the right direction, but I think what you really want is to clamp at max(24px, 1em) when 1em is set to more than that in a browser.
mediumsmart
I like the utopian default from the article:
:root { font-size: clamp(1.125rem, 1.0815rem + 0.2174vi, 1.25rem); }
but I don't need vi (I use emacs) so I would settle for: :root { font-size: clamp(1.125rem, 1.15rem, 1.25rem); }
for line length we can use ch ? 65 to 85 and shorter for the headings or whathaveyou?
Does that break the site for some users because of browser settings they have? I am all for the best presentation right after "must be readable on a phone".
pabs3
Perhaps CSS was a mistake? Before that, text was sized as the user configured it, so they got what they wanted.
rerdavies
I don't get it. Does Safari not support Zoom? Is per site zoom not the exact perfect concession to user preference? The font size settings are quite lethal unless you size EVERY THING on the page using ems -- your images, your icons, your padding, your margins: all have to be in ems if you want things to scale proportionally when font size changes. Nope. Not doing that.
If that's a horribly broken assumption on Safari, I'd be grateful if you could explain to me how it's broken.
JimDabell
> Is per site zoom not the exact perfect concession to user preference?
That would be like if every television programme broadcast audio at a different volume, so every time you watched something new you had to adjust the volume. It’s insane. The browser already knows what size text the user prefers. The only thing you have to do is let them use it instead of overriding it with absolute units. If you’ve designed something that the user needs to change their settings to read, you’ve made a really bad design.
> all have to be in ems if you want things to scale proportionally when font size changes.
You don’t want most things to scale proportionally when font size changes. The goal of a good web design is not to have the exact same raster image appear at different sizes, the goal of a good web design is to be the best presentation for the current situation – which includes user preferences, what content you are displaying, the size of the viewport, etc.
So, for instance, if you have a main content area in the middle of the page and sidebars on each side, then you might want to set a minimum and maximum width for them in ems so that the line lengths don’t get ridiculously long and it doesn’t get squashed, but the width should probably be proportional to the available horizontal width, so percentages or fr should be used for that property.
There are some things that are closely related to the font size, so for instance you should use ems to set padding around text and margins between paragraphs. But that doesn’t mean that, say, the border should be set in ems.
Basically, use the units for their designed purpose instead of thinking you need to use all of the same types of units everywhere.
rerdavies
> That would be like if every television programme broadcast audio
Well. No. It would be more like if every television program was displayed on a screen that had a different height, width, and scaling that may depend on the state of the browser at any given moment. Which is in fact the case. And is kind of the point of what we're trying to deal with here.
What I do not get for the life of me is why you would introduce a dependency on a deeply obscure user preference that I, as a perfectly literate computer user, would not expect. As opposed to scale, which is completely in your face (and also has an obscure default setting in exactly the same place if that's what the issue is for you).
And it's not like there aren't enough dependent variables I have to deal with to make sure that my UI is responsive across all common page sizes my app will encounter without introducing another one, whose benefit, frankly, just doesn't seem that compelling.
Asking because I genuinely do not get it.
uhoh-itsmaciek
The thing is, scaling font size does not necessarily mean you want to scale other aspects of the UI. Josh Comeau touches on that in this post: https://www.joshwcomeau.com/css/surprising-truth-about-pixel...
tobr
> Nope. Not doing that.
Why? I’ve started to use rlh as my base unit for almost everything, and it’s great as it automatically gives your whole design consistent vertical rhythm.
Specifically since this article is all about font sizes, and talks about the site itself as well, I will comment on the site. Its text is ludicrously large and exhibits the worst problems of fluid typography.
`font-size: calc(1.25em + .5vw)`. Please never, ever do anything like this.
On a 1920×1080 display, given a browser em of 16px, that would be 29.6px. When practically every other page around will be in the range 16–22px (mostly 18–20px, I reckon). It’s 30–70% too large.
On a 400px-wide phone with 16px browser em, that would be 22px. When practically every other page around will be in the range 16–18px. It’s 20–30% too large.
On my 1706×960 laptop display, it’s 28.5px, and has the dishonourable distinction of being the first site that I’ve actually zoomed all the way out to 50% for, and not felt any remorse at all, because that makes the text effectively 18.5px for me, right about where I reckon is right. I’ve never felt the need to go past 67% before. If it weren’t for the fluid typography, I wouldn’t have even had to, but because the viewport width is such a large part of the calculation, it decreases the effectiveness of the browser’s zoom, so the 50% is actually more like 65%. This also means that things like changing the browser’s zoom will throw you around the document willy-nilly, because it’s working against the browser’s techniques to keep you in the same place in the document.
What it talks about has a clamp() invocation to prevent values from getting too stupid, but the site itself doesn’t have that, and starts already oversized.
This is a real pity, because there’s a lot of good about the content itself—in particular, its remarks on how people accidentally make calculations assuming the browser em is 16px are spot-on. But the content is immediately compromised by the page’s crazy font sizes.