That 62.5% antipattern

I’d been meaning to rid Cover, my WordPress theme, of this particular piece of code for a while. I just never had a good reason to do so, until now.

Cover is built on top of the Underscores starter theme. When I first created it, I had yet to get into Sass or any of that pre- or post-processor nonsense. Everything was inside style.css. If you check out _s on Github, you’ll find that they, too, have made the switch to Sass. Well, that was then, and this is now.

I first created Cover and made its first commit back in January 2014. When I did so, Underscores was still using a CSS reset at its base (as opposed to a normalize, which is more in line with industry standard now), and, among other things, used the famous 62.5% font size on html.

html {
  font-size: 62.5%;

The purpose of this was to correct a text resizing bug in IE7/8 (which we no longer care about, especially since Windows XP support is no more) when em units are used. (Well la-dee-da, I use rem with a fallback to px anyway.)

It’s an antipattern, though: going from a problem to a bad solution. It changes the default font size to 10px instead of the default 16px, and as I would find, that can cause problems.

In December 2014, a commit to Underscores removed the antipattern. In the back of my mind, I had meant to fix it in Cover, too, but it seemed like it worked fine leaving it alone, so I let it be.

Fast forward to now: Cover has been released to the Internet, and while I have no delusions of popularity, it is used in the wild. One user wrote to me, informing me that it occasionally conflicted with plugins, and the result was a larger (much larger) font size than was appropriate.

It was easy enough to deduce the cause, and it gave me a reason to finally fix it. The solution, as it turned out, was actually pretty easy. It was certainly easier since I’m using Sass to build the final stylesheet.

After removing that one line from the html declaration in the reset, I only had one place to change: the rem() mixin.

When I converted Cover’s CSS to Sass, I converted all font-size properties to mixin calls. The mixin, as it existed, took the base font size (10 pixels, per the 62.5% reset), and output a rem value with a fallback to px.

@mixin rem($property, $values) {
  $px : ();
  $rem: ();
  @each $value in $values {
    @if $value == 0 or $value == auto {
      $px : append($px, $value);
      $rem: append($rem, $value);
    } @else {
      $unit: unit($value);
      $val: parse-int($value);
      @if $unit == 'px' {
        $px : append($px, $value);
        $rem: append($rem, ($val / 10 * 1rem));
      @if $unit == 'rem' {
        $px : append($px, ($val * 10 * 1px));
        $rem: append($rem, $value);
  #{$property}: $px;
  #{$property}: $rem;

The resulting output, combined with the 62.5% font size reset, resulted in CSS which was very easy on the eyes. (Because, you know, base-10.)

font-size: 16px;
font-size: 1.6rem

With the removal of the font size reset, it was easy enough to update those two lines, using the default 16px font size as the base.

$rem: append($rem, ($val / 16 * 1rem));
$px : append($px, ($val * 16 * 1px));

The resulting CSS is vastly different, as you can see:

font-size: 16px;
font-size: 1rem;

That doesn’t look so bad, though… but what about a little more custom font sizes? Let’s take a look at the post title font size declaration:

font-size: 58px;
font-size: 3.625rem;

Yeah, there we go. There’s nothing that tells the human eye that those two declarations are the same size, but they are. But that’s okay, because the line in Sass that generates the CSS is still perfectly readable:

@include rem(font-size, 58px);

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.