4 ms·

This article is not about px versus em At best, this is a tangent because the author used px as an example.

danShumway 6y ago
A couple people have brought this up, and I'll admit I don't really get what they mean. The article is pretty clearly critical of non-pixel based rendering. 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.

A couple people have brought this up, and I'll admit I don't really get what they mean. The article is pretty clearly critical of non-pixel based rendering. 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.