Originally posted on Medium.

So I’m a big fan of naming things. I’ve named my breakpoints after animals, my font sizes after trees, and my transition speeds after cats.


Well I kept running into problems where we’d have a standard size for something, then we’d introduce a smaller version, then an even smaller version, then a version somewhere in between the small and smaller version called… smallish?

When something became extra-small-ish I concluding this was ridiculous and short sighted.


Breakpoints define the different sizes we’re designing for in a project, so breakpoints are something often discussed with designers and other people. It was important to create a system that didn’t just make sense to me, but also the rest of the team. So it needed

  • to be a set of things that if you told anyone to put them in size order they wouldn’t have to think very hard.
  • to allow for new items to be added in without having to rewrite all your code.
  • not to be linked to anything physical (eg laptop, tablet, phone) as screen sizes are constantly changing. Today’s phone is the size of yesterday’s tablet is the size of last week’s tv.

And we settled on animals.

  • Wolf (80kg, 1040px)
  • Fox (14kg, 800px)
  • Rabbit (2kg, 600px)
  • Mouse (0.02kg, 480px)

Source: EOL, via Google

Then when we started designing for screens larger than Wolf, we added on Bear (1440px).

If we had a few bits of CSS to change at 700px, we could add in another animal like Hare and wouldn’t need to refactor the rest of our code.

Which sort of proves part of the usefulness of having a system like this.

Thomas Lefebvre / stocksnap.io

Font sizes

Font sizes are perhaps even more useful to create a system for than breakpoints, as you’re more likely to need to slot in new sizes.

For better or worse, the first round of development usually starts before all the designs have been finished. This means that I’ll put in the font sizes I’ve got so far (perhaps a 48px title, a 36px heading, and an 18px paragraph), but then later a new size (perhaps a 24px subheading) will be added.

Now remember that a 48px title doesn’t really mean a 48px title. It means a 48px title at this breakpoint. Regarding font sizes, what was an appropriate size for a title at Bear (like an iMac) suddenly looks huge at Mouse (maybe a smartphone), so we can’t just call 48px 48px because it’s likely going to change and not make sense anymore.

Furthermore, designs often get reevaluated throughout the project. What looked good in XD looks massive when you actually look at the real website on a real phone in your real hand, so these font sizes are also subject to change through the duration of a project.

I’ve seen systems that use numbering, such as $font-size-0, $font-size-1, etc, however this doesn’t address the issue of needing to add a new size in between later.

// Typography Sizes
$font__size--0: 122px;
$font__size--05: 73px; // urgh.
$font__size--1: 52px;
$font__size--2: 34px;
$font__size--3: 24px;

So yeah, we need another system, but not animals again - you don’t want crossover and confusion between the two systems. Why not trees? After all, font sizes are defined by their height so it makes sense to use a system of things you tend to think of by tallness.

  • Redwood (112m)
  • Scotspine (36m)
  • Smallpine (smaller than 36m)
  • Oak (24m)
  • Cactus (18m)
  • Bonzai (0.6m)
  • Seedling (small)
  • Seed (smaller)

Source: Various, via Google

Now unfortunately I’m not an expert on trees, so I’d be spending a lot of time on Wikipedia in order to find a tree between an Oak and a Cactus — you might have already realised I embarrassingly squeezed Smallpine between Scotspine and Oak.

In this case it doesn’t matter so much that not everyone in the team knows how tall trees are, because you’d still talk to other members about type sizes in terms of pixels, in the same way that you’re probably using rems but you’d never actually refer to an element as ‘the 2.1532rem title’. All that stuff is nicely tucked away in the code.

I tend to start out with Bonzai, Oak and Scotspine. That way there’s scope to slot in new sizes without screwing up your system.

Johann Siemens / stocksnap.io

Transition speeds

This is probably the most useless of my naming systems, but I’ll touch on it anyway. In fact we could regard this as an example of why you shouldn’t always let developers keep on tapping away without interruption; they’ll just lose their minds and make something useless and over complicated.

Anyway, I ended up in the same ‘extra-small-ish’ mess again with specifying transition speeds for a project. I had normal, fast, faster, fastest, x-fastest I was running out of useful names — especially when I forget which fast/er/est actually represented the speed I wanted.

So I figured cats are generally associated with speed so let’s use that.

  • Cat (48km/h)
  • Hyena (64km/h)
  • Lion (80km/h)
  • Cheetah (120km/h)

Source: speedofanimals.com

Though it ended up being more trouble than it’s worth remembering that I use Lion for link hover states, Hyena for fading in lazy loaded content, and Cheetah for weird things like smoothing out border-width growth.

Probably a better system for transitions speeds would be

  • link-hover
  • lazy-loading
  • instant

I’ll be honest, I just wanted another system. I was having so much fun with Animals and Trees that I just kept on going.

Maximilian Wachter / stocksnap.io

So this might all be well and good, but you might be wondering how best to apply this to your styles. I’ll cover that in another post.