A few weeks ago I got distracted when I discovered — to my horror — that occasionally the font size on my site was 1.24924375rem instead of the desired 1.25rem. Of course nobody would notice this. But I was annoyed with myself and wanted to figure out why.

My site is very old. When I started my site, people used desktop computers, mostly with 640✕480 or 800✕600 monitors. I designed my content to have a width of 450px so that there was space for browser sidebars, scrollbars, toolbars, etc. As resolution increased, I designed newer content to be 600px wide.

Over the years, monitor resolutions kept increasing, and then shrank when we got web browsers in cell phones and tablets. My site didn’t take that into account. I decided to study how other web sites handled varying screen sizes. A common technique was to use “breakpoints” to switch layouts. In this visualization, the vertical axis is the browser width and the horizontal axis shows the content vs margin:

I didn’t want to maintain multiple layouts. I wanted one layout that adapted smoothly based on the browser width, with no discontinuities:

In 2017 I went through my pages one by one and migrated them from the fixed 450px or 600px layout to use the new layout. During the transition my build systems supported all three.

In 2020 I wanted to take into account the reader’s preferred font size. I switched from px units to rem units. I didn’t realize until a few weeks ago that I got that conversion slightly wrong.

I decided to investigate. In converting px units to rem, I divided everything by 16. But somewhere in the intermediate calculations, I had rounded 0.625 to 0.6. I had made the mistake by manually calculating the breakpoints, and I fixed it by manually calculating everything again.

I decided I should automate the calculations. I already had most of the code written for the interactive diagrams, so I adapted it into a calculator. I can enter the breakpoints and it generates the CSS:

While playing with the calculator I realized I didn’t like entering a lower breakpoint (515.5px @ 550px). I looked through my notes from 2017 and saw that I had actually calculated the lower breakpoint from a more fundamental value: the slope of the line on the diagram. A slope of ⅓ means that for each additional 3px of browser width, 1px goes to the left margin, 1px goes to the content, and 1px goes to the right margin. Whether that’s the best ratio I don’t know, but it’s what I’ve been using.

The last thing I did was to move the calculation to run inside CSS. This wasn’t feasible in 2017 but it works in current browsers using functions like min() and clamp(). I also use round() to make sure diagrams have an integer width, so that any <canvas> elements aren’t fractionally sized.

Overall I think the first half of this project was hard to justify. Fixing the bug changed a fraction of a pixel, and that shouldn’t matter to anyone. But the second half of this project is potentially useful. I found a set of formulas that lets me adapt my layout to other sizes for future projects.

Try the interactive visualization here^[1].