from Hacker News

Reimagining Fluid Typography

by BaudouinVH on 2/28/25, 2:28 PM with 25 comments

  • by chrismorgan on 3/2/25, 10:43 AM

    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.

  • by jasonjmcghee on 2/28/25, 11:37 PM

    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.

  • by notpushkin on 3/2/25, 4:38 AM

    > 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); }

  • by greggman25 on 3/2/25, 6:43 AM

  • by mediumsmart on 3/2/25, 10:29 AM

    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".

  • by pabs3 on 3/2/25, 9:58 AM

    Perhaps CSS was a mistake? Before that, text was sized as the user configured it, so they got what they wanted.

  • by rerdavies on 3/2/25, 6:14 AM

    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.