The 62.5% Font Size Trick
AleksandrHovhannisyan opened this issue ยท 11 comments
I really enjoyed you article. I too have been using REMs at a 1/10 ratio and setting the body
to a good default size. When you're going through an application and REMs are used everywhere, it's tough to see something like 0.5625 rem
and have to calculate what it equates to in pixel units. I'm a huge of of developing without thinking. There's so much to remember and to build already, there's no time to waste to calculate REM units.
Great article!
This was such a good article. Thank you. I am learning CSS via The Odin Project, and will use this technique here on out. My question (and maybe this could be another follow up article)... when and where should I use EM? (Or should I just get used to sizing everything in REM?) I would imagine that padding paragraphs, buttons etc with EM would be useful?
@MondoBurrito Good question! I tend to use rems for everything, but I've recently been debating whether this is actually a good practice. I haven't quite made up my mind yet.
If you're interested, there was a good thread about it on Twitter. The takeaway seems to be that you may want to use rem
only for font-related properties (like font size, line height, letter spacing, etc.) and reserve pixels for everything else.
I tend to avoid em
these days since it's less explicit than pixels/rems, and it may yield values that aren't part of your design system's spacing variables. Especially for component libraries, the general advice is to avoid em
if the element you're styling doesn't have an explicit font size. Otherwise, it'll style itself based on its parent font size, which could yield unexpected results (imagine a button setting its padding based on the parent's font size, and then you insert this button in a context where the font size is set to be largeโnow the button's padding is unnaturally large). One place where ems might be useful is for paragraph spacing. But even there, you could still use rems.
This is a good idea, unless it isn't.
E.g. when you don't have 100% control over all the CSS on your website. Think of 3rd party components (e.g. cookie consents so popular these days, online chats, etc.), libraries like Bootstrap etc. - these sometimes expect that the root font-size is somewhat reasobanle and therefore use rem as well. But if you change the root font-size, suddenly those 3rd party components act accordingly.
@lcech That's actually a really good point and something I hadn't considered. While the technique outlined in this article can be useful, it could also make it difficult to incorporate other libraries (CSS or component) in the future.
On the other hand, I tend to prefer unstyled component libraries like Radix UI since they allow you to keep your own conventions.
It's definitely a tradeoff. Thanks for bringing this up!
Excellent article.
For the Tailwinders out there, I just started making custom classes by editing tailwind.config.js with calculated rem values.
These classes are referencing pixel sizes as they will be in a default, uncustomized browser. But they will output rem values. So then when I see the designer has used 12 px, I can go "text-px-12". Seems like a simple workflow?
theme: { fontSize: { 'px-10':'.625rem', 'px-12': '.75rem', 'px-13': '.812rem', 'px-14':'.875rem', 'base': '1rem', 'px-20':'1.25rem', 'px-34': '2.125', },
Is there any evidence that, for modern browsers, setting something like html { font-size: 10px; }
will not be scalable whereas html { font-size: 62.5%; }
is? Or is there any evidence that users change their default font size? I see these claims made regularly as if this is common accessibility knowledge, but I have yet to see anyone actually test this beyond a theory. ๐คทโโ๏ธ
I guess another way to say it: scaling font size seems like a feature of a previous generation of browsers, whereas modern browsers all advocate zooming (and make it easy to do), which works regardless of that setting, so I can't see any reason why html { font-size: 62.5%; }
is still applicable. Unless someone has some current research that supports it.
@matthew-dean Honestly, I'm not too sure! Fwiw, I recently moved away from the 62.5%
trick myself because of the point brought up by @lcech. I think I now prefer to use rems as-is or an intermediate calc utility (in a CSS preprocessor) to convert pixels to rems for me.
Edit: See my related post on why you should use rems for font size. There, I've linked to an article from 24a11y on why pixels aren't great for responsive scaling (even though you technically can still zoom the page).
I actually tried using the 6.25% approach to make the translation super simple from my figma artboard(1440px) to breakpoint(1440rem), then inspired by the website of anytype and how they use a font-sizer custom property as the multiplier to make root font-size fluid. I loved the simplicity and the very little need to tweak anything beyond when the initial numbers are thoughtfully locked in. The only downside is, as @lcech pointed out, when i decided to pull in other libraries. anything that touches sizing needs some scrutiny for them to work properly within this new construct. But all in all, I wanted to echo your stand regarding the validity of the 62.5%, and by extension, even the 6.25% as well.
Using 6.25% will bring your font size under WebKit's 9px "readable" minimum for scaled font sizes, which will cause the rest of your website to scale funny.