The 62.5% font-size trick (+Infographic)
Many a time, we use tools to convert
px to a relative unit such as
rem. Yet, we get weird-looking decimals like 0.9375rem. Problem is, afterward, it's hard to know if 0.9375rem is 13px, 14px, or something else.
The 62.5% font-size trick helps us use a pixel value along with a relative unit. This way, we do without conversion tools and still have better readable values.
As introduced by Richard Rutter in 2004, you only have to include the style
font-size: 62.5%; on the body element. Now, you can specify 1.7em instead of 1.0625em for 17px, 1.8em instead of 1.125em for 18px, and so on.
Useful technique right?
Well, some think it's pointless, archaic, and breaks expectations. As such, it shouldn't be recommended. In fact, Richard Rutter who introduced it recommends something else now. So, case closed? Not so fast.
No doubt, some of these are valid reasons at some point. Good thing is, we were mistaken. It turned out that the problem isn't the technique but something else. This post takes you through time to understand the misconceptions.
Let's start with the essence of converting
rem and still think in
Why think in pixel (px)?
The lifecycle of a web design project starts and ends with px for measurement. UI Designers design in px, and Browsers paint in px.
Thinking in pixels makes it easy to do the following:
- Translate UI Design to code.
- Read the code in the editor.
- Troubleshoot the code in the browser.
This ensures a better development experience. In addition, the mental model is maintained across the team.
Why convert px to em or rem?
If it's okay to let users decide at what font size it's best for them to read a webpage, we need to use font-relative units.
Of course, with px, users can enlarge text by zooming in or out. Yet, changing the browser's font size helps them set it once and avoid zooming each time they visit a webpage.
rem makes the element responsive to the user's preference.
Reasons said, we shall now evaluate the 62.5% trick by its compatibility with
rem of both author and 3rd party stylesheets.
Compatibility with em units of Author Stylesheet
Back in 2004, browsers supportted
em units, not
rem. By design,
em compounds as it can relate to the parent's font size. Of which the parent, if uses em, relates to its own parent. And it goes up to the user's preference in the browser settings.
Because em compounds, the 62.5% trick is only useful for top-level ems. And this is totally fine!
Compatibility with em units of 3rd Party stylesheet
Recall the trick's style of
font-size: 62.5% on the body element? This will compute to 10px if the user's preference is 16px (a default in the browser's settings).
This is no problem for the author's stylesheet. Since the expectation of 16px is met with 1.6em as per the trick. Nor is it an accessibility concern because 62.5% is relative to the user's preference.
However, a computed value of 10px is no expectation for 3rd party stylesheets like that of the browser.
Moreover, it becomes easy for the user's minimum font size to kick in if declared. (Mozilla Firefox used to have a value of 12px but not anymore.)
Anyways, we can resolve both issues with a reset. In any of the following 2 methods.
Reset Method 1
We can reset on each HTML element. It'd look like this
If you intend to leverage the browser's style, this method won't help. For components where you'll need custom styles, this method becomes useful for top-level
Reset Method 2
An easier way to reset the 62.5% trick for compatibility with em-based 3rd party stylesheets is to do the following.
- Move the style
font-size: 62.5%;to the
font-size: 1.6em;on the
Now, we are back to square-one! Here's why:
- we've used the trick's one-time benefit on the body element.
- the current state is as good as not specifying the trick
So, if anyone says it's pointless, that's a reason!
But, there's still a use-case.
Compatibility with rem units of Author's Stylesheet
Around 2014, a decade after this trick was introduced, rem gained most browser support. Unlike
rems don't compound as they relate to the root's font size.
Hence, the 62.5% trick becomes useful for all occurrences of rem in the author's stylesheet.
Hold on, spoiler ahead:
Compatibility with rem units of 3rd party stylesheets
The wave of rem's simplicity blew across the ecosystem. For example, Bootstrap, a 3rd party stylesheet, also adopts rem for version 4. Let's skip the semantics of
rem for now.
Because the computed root's font-size is 10px, the 62.5% trick becomes useless for all occurrences of
rem in a 3rd party stylesheet.
At this point, you may give up on the trick because it only supports top-level
ems and author's
rem. Leaving out 3rd party stylesheets that use
But, I implore you to take a step back and consider if it's semantic to use
rem units in a 3rd party stylesheet.
Should 3rd party CSS use rem?
Let's examine this via the user of a 3rd party CSS, which we shall refer to as the Client.
It's fair to say: a client should be able to use 1 or more 3rd party stylesheets. Each on different components of a page.
And if the client wishes, they may font-scale a component independent of another.
Unfortunately, 3rd party CSS with
rem units will have values tightly coupled to the client's global font size. Hence, they won't be responsive to a local font size.
This becomes a problem when a client needs to scale a component by its
local font size. A problem 3rd-party CSS authors can avoid if they use
Clearly, this is a case of
Picking on Richard Rutter's guide for setting font-size of an element in 2016, he said:
use rems for global sizing, use ems for local sizing.
Earlier in 2014, Chris Coyier puts it explicitly in the font sizing idea:
Actual text elements (h1, h2, p, li, whatever), if you size them at all, are sized in em, and thus become relative to the module. This way, you can adjust font-size at a module level.
Thus, since 3rd party stylesheets are meant to be distributable, it makes sense that they can adapt locally to wherever they find themselves. Using
em, rather than
rem, in 3rd party CSS makes them more universal and responsive.
That said, there might be a case scenario where a 3rd-party CSS author wouldn't want an element to scale via a component it find itself. Neither can they afford to use an absolute unit.
At that moment,
rem fits the scenario. Only that, a change in the client's root font size affect components of other 3rd party CSS.
What to do?
With CSS Variables, 3rd-party CSS can make global
rems local to their own stylesheet. Implement looks like this:
This means, 3rd-party CSS should use
emfor scope-able relative values
remfor non-scope-able relative values
Using appropriate units in a 3rd-party stylesheet ensures the modified 62.5% trick is useful for all occurences of
rems in a host stylesheet.
To use the modified 62.5% font-size trick, simply state the following properties in your stylesheet
font-size: 62.5%;in the
font-size: 1.6remin the
Here's the code:
There are a number of concerns around the 62.5% technique. Below are some and my humble opinions.
It breaks 3rd party stylesheet
Ironically, this is good as it forces library authors to adopt
em. This in turn, give developers more flexibility.
It may render smaller when users use the minimum font size (MFS) setting
With or without the technique this effect will kick in if the computed font size is less than the MFS.
Despite that, there's no cause for alarm. Because, the modified trick decreases the font size on the
:root and resets it on the
body. Hence, elements within the
body gets their expected value.
It ruins user preference or accessibility
Big NO. The trick uses a
% unit which is relative to the user's preference in the browser settings.
You can't integrate it into a stylesheet that doesn't use the technique
That's true until we've a tool that convert rem values of 62.5% to 100%.
No point. It's not necessary
if you're locked-in on a 3rd party CSS that uses
rem, consider the following alternatives to the 62.5% trick.
Each of these alternatives is evaluated based on the readability in both the source code and the DOM.
calc can be used to convert px to em/rem on the go. But, it isn't as simple to read or write like the 62.5% trick.
In the code below, 18rem will be read as 18px both in the source code and the DOM.
Below is another variant. It's more verbose than the previous.
Here, we can easily read the value of the
Functions from CSS preprocessor are easy to read in source code but not in the DOM
In the code below, we'll read it as 15px. But in the DOM, it'll be 0.9375rem.
You can use a tool to precompile values. And leverage on CSS variables for better readability.
The downsides to this approach are,
- you need a tool,
- you can get an overwhelming list of values. Especially, when it comes to minutiaes like spacing which are highly dependent on visual perceptions.
The 62.5% font-size trick is still relevant today! Even among the alternatives. The only challenge is getting 3rd party CSS to use appropriate units. Units tailored to how its user may use the package.
So, are you convinced already? Will you be using the 62.5% trick anytime soon? or You've damned it? Let's discuss on Twitter.
By the way, there's an infographic I made to summarise the 62.5% font-size trick in one shot. You can download the infographic for free and get design updates if any come up.