The Dilemma of Naming Font Size Variables

The Never-Ending Problem of Naming Font Size Variables

Most sizable projects settle on a set of predefined font sizes, usually stored as variables with names that attempt to bring some order to the chaos. The alternative—scattering raw values like font-size: 18px throughout the stylesheet—leads to a mess of mixed units (px, rem, em) and inconsistent sizing. Variables exist precisely to avoid that: they provide structure, maintainability, and consistency.

But naming is hard, and font size variables are a perfect example. If you have $small, $medium, and $large, what do you do when a designer introduces a size that falls between $small and $medium? Or one that's larger than your current maximum? You could refactor, renaming $small to $xsmall and letting $small take the new value—but that risks breaking existing usage. Or you could try to invent a name like $small-medium, $small-2, or $smedium, none of which feel right.

This issue extends well beyond font sizes. Paddings, margins, widths, heights, border radii—any length-based value requires the same kind of structured thinking.

:root {
  /* Font size variables */
  --small: 12px;
  --medium: 16px;
  --large: 24px;
}

Why Common Approaches Fall Short

One tempting solution is to skip the scale entirely and use functional names based on usage, like $form-label or $button-font-size. That might work in isolation, but it quickly creates a broken system:

$small: 12px;
$form-label: 14px;
$medium: 16px;
$large: 24px;

Suddenly your scale mixes size concepts with component concepts. Can an alert use $form-label? Should it? And what happens when the same value needs to appear in multiple places—do you duplicate the variable under different names? That's a recipe for inconsistency.

Some projects try Greek letters—$alpha, $beta, $gamma—but that raises an immediate question: is $alpha the small one or the large one? And what comes after $alpha? $alpha-large? Few developers can confidently order Greek letters by size without looking them up.

Even percentage-based scales need variables, as Geoff Graham discovered with his own approach to font sizing:

h1 {
  font-size: clamp(var(--text-size-large), calc(var(--text-size-base) * var(--text-size-scaler)), var(--text-size-huge));
}

Looking for a Better System

The real problem is that font size scales need to accommodate constant additions. Modern development workflows—MVP, Agile, continuous iteration—mean new sizes appear regularly. A naming scheme should be flexible enough to handle insertions without breaking changes, and intuitive enough that developers don't need to consult a config file to understand it.

Existing Systems Worth Considering

Before inventing something new, it's worth examining what's already out there.

The metric system offers prefixes like $milli, $centi, and $kilo. It's intuitive if you're familiar with SI units, but it's also finite—the system has predefined levels with no room for insertion. There's no convenient "between milli and centi" option.

Traditional typographic names—Nonpareil, Pica, Cicero, Great Primer—are historically fascinating but practically unusable. The names vary by country, the same name can refer to different sizes in different contexts, and they're so type-specific that applying them to breakpoints or spacing feels like a stretch.

Everyday objects offer more creativity. Maybe chili peppers?

The idea has appeal—who wouldn't enjoy writing font-size: $tabasco?—but it fails on universal intuitiveness. If you don't know peppers, you can't order them by heat. And the Scoville scale bottoms out at zero with the bell pepper and tops out with the Carolina Reaper, so the system isn't infinite anyway.

Balls have similar issues:

Most people can roughly order a ping-pong ball, tennis ball, soccer ball, and beach ball by size, but the fine-grained distinctions get fuzzy. Is a golf ball larger or smaller than a ping-pong ball? And a bowling ball and soccer ball are actually the same diameter. Not exactly a precise scale.

The Problem with Numbers

What about naming variables directly after their value, like $font-18?

$font-14: 14px;
$font-16: 16px;
$font-24: 24px;

It's infinite—there's always room for another size. But it tightly couples the variable name to its current value. If you need to change $font-18 from 18px to 19px, you're looking at a rename operation across the entire codebase, updating the variable definition and every usage site. That's barely better than hardcoding values.

Animals, however, offer an intriguing possibility:

Something like this:

$mouse: 12px;
$dog: 16px;
$hippo: 24px;

Need something smaller than a mouse? There's $bee, $ant, or $flea. Larger than a bear? Try $moose or $hippo. Bigger than an elephant? $whale—or go prehistoric with $t-rex. The animal kingdom provides a nearly infinite, intuitive scale that can accommodate any new size by simply inserting the right species. And it's playful, too: writing font-size: $squirrel brings a little joy to otherwise routine code.

Final Thoughts

The codebase is where developers spend their working hours. It deserves the same consideration as any other workplace environment. The naming system you choose for font sizes—or any scale—should let colleagues jump in and understand the organization immediately, whether they're working with type, spacing, or breakpoints.