Three of the four problems the author sees with fonts:
> Unpredictable: you can’t guess what you’ll get. 16 pt means how many pixels, exactly?
> Not practical: you can’t get what you want. Want letters to be 13 px tall? Can’t do it.
> OS-dependent. Get different rendering when opening a document on a different OS. Can’t share editor config between macOS and Windows.
Most of those complaints are relevant to what I'm talking about:
- A pt measurement unit might be different between computers, which the author considers a serious problem to solve, and the web considers to be a fact of life to be embraced.
- There's no way to specify exactly how many pixels a font takes up, which is not necessarily a problem people should be trying to solve.
- Different OSes might display your font at different sizes, which is, again, not a problem that most native apps should be worried about.
The author does have a (somewhat) legitimate complaint that `em` units are somewhat arbitrary. It's a little bit weird because it doesn't acknowledge that in this case "arbitrary" means specifically chosen by the font designer to incorporate the best spacing for their font. But whatever, I can get behind an effort to make it easier to compare fonts to each other, and it doesn't seem like there's a compelling reason to force everyone to follow the font designer's choices.
But the author's solution is to use pixels (or some other unit-based non-relative measurement that will be guaranteed to render at the same size across OSes):
> Specify cap height, not em square size.
> Specify it in pixels.
In short, I share the author's frustration that there's no way to relate different fonts to each other in a reliable way, I share their frustration over working with line-heights, but I don't see how their criticism of pts and need to have font size perfectly synced between Windows and Mac works into that. In a responsive world, it should not be an issue for your app that font size might be a different number of pixels than you set it as.