Skip to content Contact us

Contact form

SASS-variables
Technology by Aleksandr Beliaev,

How to name size variables in SASS – useful tips for a frontend developer

One frequent problem a frontend developer may encounter is to choose how to name SASS variables of same type.

This is not a big problem with colors or font names for example — just use the most literal name or assign a term in any conceptual space. For example, we can name the #ff0000 colour in many ways. $danger (from a user point of view), $accent (from a designer point of view), or simply $red are all a fairly good fit.

This becomes more problematic when it comes to rankable types of variables, for instance, font sizes. A widespread convention (popularised by web prototyping frameworks such as Bootstrap) is to take a size most common for this project (or a supposed “industry standard” such as 16px) and accept it as a “medium”. Everything bigger than that would end up therefore being $large, $x-large or $super-large, everything smaller — $small, $extra-small, $xx-small etc.

Such a naming system quickly goes out of control. The most frequent issue is that it’s poorly scalable and maintainable. What if you need to add a new font size and that size happens to fit between already existing $small and $x-small sizes? Should you rename all the $x-small variables to $xx-small, or should you steer of creating a variable in this specific case? Even defining the “medium” variable might be pretty misleading. Sometimes when you start coding your first layout may not even have the most prevalent font size in the project, and you’ll inevitably make an incorrect choice here.

Getting out of the iron maiden

The burden of finding a meaningful and robust label for a font size (or any size whatsoever) can be relieved if we simply replace names based on ranking with names that are inherently not orderable. How designers work can provide us a good insight on this. In UI design you don’t usually rank font sizes you use. Instead a font size along with other visual features is simply assigned to several places in a layout, serving different roles in each (in common UI design software this is usually called just styles). For example, formatting that is 12px, bold, uppercased could be used for a sidebar section title, but it could also be used for the footer copyright. It doesn’t matter what those roles are. What does matter is that the reused style is quite coherent and a good designer would avoid amending it in specific places out of fear of breaking visual consistency.

What follows from this is that it is neither necessary nor sensible to name your sizes in relation to each other. Non-rankable names work better because they are more flexible. It might be a good idea to have names according to the design role of certain size (for example, $size-section-title or $size-teaser-title). A name in the end might be even totally random. What counts is that a name would not semantically conflict with any location where it’s (re)used and therefore would not have to be changed frequently.

In designers steps

So, designers reuse font sizes within groups of typographical features (aka styles). Couldn’t we mirror this in the frontend work? A visible and non-hacky way to do this is to create a SASS map of all the text styles we use. It could use some hierarchy inside, for example, we could separate the styles into 2-3 big chunks by font family and add responsive changes within each text style:

$font-styles: (
  'body': ( // corresponds to a chosen "body" font, for example, Proxima Nova or Roboto
    'regular': (
      font-size:$font-size-base,
      line-height:1.6
    ),
    'teaser-content': (
      font-size:16px,
      line-height:1.5,
      font-weight:300 
    ),
    'single-summary': (
      font-size:32px,
      line-height:1.2,
      font-weight:300 
    ),
  ),
  'headings': ( // corresponds to a chosen "headings" font, for example, Titan One or Eczar
    'teaser-title': (
      font-size:28px,
      hyphens:auto,
      letter-spacing:.5px,
      line-height:1,
      'medium': (
        font-size:20px,
        line-height:1.16,
      ), 
      'large': (
        font-size:24px,
      ), 
    ),
    'page-title': (
      font-size:42px,
      line-height:1,
      'medium': (
        font-size:52px,
      )
    ),
  )
);

To actually apply a text style, as a part of this technique we could have a mixin that would accept font family name and text style as parameters:

// example usage: 
.c-contentarea__title {
  @include u-set-typography('headings', 'page-title');
}

@mixin u-set-typography($typeface-name:'body', $style-name:'regular') {
  
  $this-typeface: map-get($font-styles, $typeface-name);
  $this-style: map-get($this-typeface, $style-name);
  
  @if $typeface-name == 'body' {
    font-family:$ff-body; 
  }
  @if $typeface-name == 'headings' {
    font-family:$ff-headings; 
  }

  @each $property, $value in $this-style {
  // inspired by https://github.com/sass-mq, this assumes that you have your breakpoints in a separate map where key is the name of a breakpoint ('desktop') and value is in pixels (1110px)
    @if map-has-key($breakpoints, $property) and type-of($value) == 'map' {
      @media screen and (min-width: $property) {
        @each $subproperty, $subvalue in $value {
          @if $subproperty == 'font-size' {
            $subvalue:$subvalue;
          }

          #{$subproperty}: $subvalue;
        }
      }
    } @else {
      @if $property == 'font-size' {
        $value:$value;
      }
      #{$property}: $value;
    }
  }
}

Don’t overthink it

This technique we have used in several real projects as a part of our WordPress boilerplate theme. With the text styles map and the mixin we actually don’t need to think about how to name different font sizes at all. Instead we just follow a natural workflow of UI design — just taking whatever styling a designer has provided, with less organising stuff for the sake of organising. Hopefully this tip (and maybe the text styling technique) will make your frontend work faster with less things to worry about.

See all blog posts

Read next

See all blog posts in this series

More in this series

See all blog posts

More from the blog

Our offices

Contacts