One clarifying point & potential gotcha: the root element is actually the html element.

The example works as-is since the body font-size is identical to the browser default for the html element. But if the font-size for the html element changes at all, you’ll see the rest of the rem renderings change.

Be especially wary of this if you use tools like Normalize.css or other frameworks!

I don’t see that rem is a solution to the first problem, since older browsers don’t support them and IE has had page zoom since version 7 released in 2006. Are web developers still really supporting older browsers than that?

Second, I feel that instead of rem, why not give developers a Javascript API for the page zoom? At glance, I don’t see any security implications. It seems it would be a whole lot easier. But until then, I just don’t put font resize menu on webpages. People that are sight impaired and need to resize a web page know how to do so with their own browsers or if they don’t are better off learning it than having a specific menu on one page they visit.

For example:

@font-size: 16;
@em: @font-size*1em;

h3 {
font-size: 18 / @em; // which is output in CSS as 18 ÷ 16 = 1.125em
}

Hey, Jason—great points! The em does have a healthy amount of contextual baggage, it’s true. One thing that I’ve found helpful is to try and minimize inheritance whenever possible, and be as atomic as you can with your font-size declarations. À la Nicole Sullivan’s fine work on OOCSS. (https://github.com/stubbornella/oocss/wiki/faq)

Wait… I confess that I skipped the part about the rem unit – that’s how frustrated I am with the em! – but sounds like I’ll be waiting for the rem unit to be fully supported. That sounds awesome and thank you for mentioning it in this article.

I’m glad you found value in my talk, Ethan. At the risk of appearing to speak for Mr. Marcotte, I’ll say this about base sizes and measurement precision:

According to Rich Rutter’s research, setting a base size of 100% yields a good amount of cross-browser consistency. Now, browsers and devices have changed since Rich wrote that ALA article, but there is still value in the idea of basing measurements on a device’s standard type size.

A pixel is not a pixel is not a pixel. In other words, there are no absolute sizes when it comes to measuring web type. Everything is relative. So a sensible place to start is by zeroing our scales to the “normal” of a given environment.

What does that mean for systems of measurement like modular scales? It means more math. Proportionally, there is no change to a given scale. But there are different numbers a calculator would need to produce for us. Remember the modular scale calculator’s third column of results (the percentage of 13px)? Like that. But rather than base that range of specific numbers on 13px, we’d base it on the pixel size that most closely matches a given environment’s “normal”.

For example…

First, I would look at a range of sizes of a web font specimen in a given environment (say, on some new tablet thingy), and find the size that looks best to me (maybe 18px).

Next, I would set some type at a font-size of 100%, view it in that same environment, and see which pixel size it most closely matches (let’s say 16px).

Then I’d essentially have fuel for the target / context equation that Ethan explains so nicely in this post: pixel size that looks best (18px) / pixel size that most closely matches 100% (16px).

To create a modular scale, I’d plug 18px in as the starting type size. What I’d want to see in the calculated results is a column of numbers expressing my scale as a multiple (rather than a percentage) of 16px. I could use those numbers as my REM values. And I’d want the ability to make as many of this kind of column as necessary, to support calculations based on different environments’ “normal” font sizes.

Thanks for asking this good question! Maybe it’s time I updated the calculator….

Do you have any thoughts on taking that methodology into consideration when starting with a body font size: 100% and then using em’s, etc.? It seems like there’s a greater chance to start with a font rendering outside of the “sweet spot” resulting in funky letterforms.

Thanks!