Let the record show, I was correct during the recording—and that’s the important part, right? Let’s review what Figma Variables are, then explore how to use them with your typography system.

A Brief Review of Variables in Figma

In Figma, Variables are placeholders for reusable values—just like JavaScript. These values include colors, numeric values, and more.

Once set, you can use them across different design elements in your Figma designs. Variables can also be shared with your team and used across multiple Figma files. This makes it easy to make sweeping changes to your design system with a few button clicks.

Using Variables to Control Typography in Figma

Previously, Figma’s variables were great for colors and spacing, ensuring consistency. However, we lacked the same flexibility with fonts. We had to use various styles and components for different themes or brands. Styles are still incredibly useful, but they lack the ability to change a single value used by multiple styles. This makes a task like switching a font incredibly tedious as you’d have to update every single style. In the course, we explored some approaches using various plugins in an attempt to automate this process, but the constraint was still there. This was a significant limitation and meant that we had to combine multiple approaches in order to maintain consistency throughout our design system.

Now that variables can be used with typography, you can now define variables for font settings. Figma now supports using variables for the following properties: 

• font family
• font weight & style
• font size
• line height
• letter spacing
• paragraph spacing & indentation

Each of these properties can be controlled using the same variable types that we saw when we walked through variables during the course, with numbers and strings being the most pertinent for defining typography properties. For example, you can use a string variable to define the font family.

With the values set, you can select a variable when selecting the font family in the left-side panel in the Figma canvas. Changing the variable will now change all text in your designs that reference this variable, allowing you to quickly make changes across your entire design by updating a single value.

Here’s a quick video demonstrating setting a block of text to a variable, then changing that variable:

There are still a few limitations. For example, variables don’t support percentages for line heights. Variables also don’t autocomplete for spacing or line height. Hopefully, Figma will address these soon.

Using Variables with Modes

In the course, we used Variable Modes to switch between light and dark themes as well as different responsive breakpoints. This approach also works with our new typography variables allowing your variables to point to different variables depending on what mode you’re in.

Imagine managing font sizes for different viewports. Create a “Typography” collection in the variables editor. We’ll create two modes: Desktop and Mobile. Depending on which mode we’re using the variables will have one of two values as seen in the screenshot below.

With these changes, we can switch to a smaller set of font sizes when designing for mobile. If we need to change the font size across all of our mobile views, we can simply update the appropriate variable. 

One thing that  makes variable modes powerful is that any layer set to Auto will inherit the any mode set on the parent. This means that if you switch the mode of the frame containing multiple text elements from Desktop to Mobile, all of your typography will automatically update to the values defined in the Mobile mode.

Being able to support different font sizes and spacing across viewports is the most compelling application of typography variables for me, personally. But, they could also be useful if you had to support multiple brands or themes in your design system. 

For example, you could have a different mode for each brand theme you support. You could also define different font families for your Android application as opposed to your iOS application. You could even define different font sizes for your marketing website as opposed to your application’s user interface.

What About Styles?

Prior to supporting variables within typography in Figma, we used Styles—and these are still useful. A variable can represent one value. Styles, however, can store a composite of values (e.g. font family, size, and line height). This gives us the ability to use variables as primitives, define the font, size, and spacing for our typography and then save that combination as a style.

It’s less about whether to use styles or variables and more about how to use styles and variables. What’s really cool about this is that you can use a single variable as part of a number of different types. Updating that variable will then immediately update every style that relies on that variable.

In Conclusion

Introducing variable support for typography in Figma is definitely a welcome change that we’re already beginning to leverage in our internal design system at Temporal. Variables now unifies colors, spacing, and typography using a single approach. Combining variables with styles is powerful, as well. Variables allow for individual changes, while styles provide preset options. This mix helps us build and update design systems with a lot less hassle.

That said, some features are missing, such as percentage line heights and spacing suggestions. But, I suspect those features will be coming soon and I’ll have to update this yet again.

In the meantime, I encourage you to take the typography in one of your existing designs and update using typography variables. I suspect you’ll be pleasantly surprised with how easy they are to work with.

Here’s the outcome, incorporating a play button to show you it can be done via user interaction:

This is achieved with the help of “masking” and perfectly placed conic-gradient(). The browser support for conic gradients is fine, but we’re also going to be using CSS’ @property here which isn’t in stable Firefox yet, but is in Firefox Nightly.

Note: Masking is a graphic technique where portion of a graphic or image is hidden based on the graphic or image layered over and/or under it, based on either the alpha channel or the light/darkness of masking image.

In our example, the masking is done using CSS Blend Mode. I’ll mention later why this is the method I’d chosen instead of CSS Mask (the mask-image property).

Let’s get started with the HTML. Some black text on a white background is a good place to start. This is technically our “mask”.

<p>Marasmius rotula is... </p>

p {
  background: white;
  font-size: 34px;
  line-height: 42px;
  text-align: justify;
}

A container element is added around the text to serve as the graphic to be shown through the mask/text. Also, a CSS variable is used in the container element to assign the line-height. This variable will later be used in the gradient.

<section class="text">
  <p>Marasmius rotula...</p>
</section>

section.text {
  width: 420px;
  --lH: 42px; /* line height */ 
  
  p {
    background: white;
    font-size: 34px;
    line-height: var(--lH);
    text-align: justify;
  }
}

Now, we write up a conic-gradient() as the background for the <section> container, with the gradient’s height same as the para’s line-height, and set to repeat for each line of text. The gradient should look like an arrow (triangular at the tip) passing through the text.

section.text {
  width: 420px;
  --lH: 42px; /* line height */ 
  background: repeat-y left/100% var(--lH) conic-gradient(white 265deg, red 269deg 271deg, white 275deg), white;
  
  p {
    background: white;
    font-size: 34px;
    line-height: var(--lH);
    text-align: justify;
  }
}

We won’t see anything yet since the “black text with white background”, <p>, is blocking the gradient behind it. However, the gradient looks like this:

We’ll now turn the gradient into an animation, where it grows from zero width to however much width is needed for it to cover the entire text. For the moment, let’s make this transition animation to take place when we hover the cursor on the text.

@property --n {
  syntax: "<length-percentage>";
  inherits: false;
  initial-value: 0%;
}

section.text {
  width: 420px;
  --lH: 42px; /* line height */ 
  background: 
  repeat-y left/var(--n) var(--lH) conic-gradient(white 265deg, red 269deg 271deg, white 275deg), white;
  
  p {
    background: white;
    font-size: 34px;
    line-height: var(--lH);
    text-align: justify;
  }
}

section.text:hover {
  --n: 340%;
  transition: --n linear 2s;
}

The --n custom property is used to assign the size of the gradient. Its initial value is 0%, which increases with a transition effect when the text is hovered, and hence the gradient grows in width.

We still haven’t masked our example. So, once again, only the text will be visible. Let me show you how the gradient animates, separately, below:

Note: @property creates a custom property that has a known type, hence the property value can be animated. The custom property may not have been able to be animated otherwise.

Let’s now drop the blend mode (the mix-blend-mode property) into the <p> element to finally see the effect.

@property --n {
  syntax: "";
  inherits: false;
  initial-value: 0%;
}

section.text {
  width: 420px;
  --lH: 42px; /* line height */ 
  background: 
  repeat-y left/var(--n) var(--lH) conic-gradient(white 265deg, red 269deg 271deg, white 275deg), white;
  
  p {
    mix-blend-mode: screen;
    background: white;
    font-size: 34px;
    line-height: var(--lH);
    text-align: justify;
  }
}

section.text:hover {
  --n: 340%;
  transition: --n linear 2s;
}

For the sake of operability, instead of on text hover, I’ll move the animation to take place with user controls, Play and Reset. Here’s the final output:

The reason we didn’t use mask-image, as I mentioned before is because Safari doesn’t render the output if I use multiple gradient images (on top of the conic-gradient()), and also has a blotchy implementation of box-decoration-break during animation, both of which are important to work correctly for the effect I wanted to achieve.

That said, here’s a Pen that uses mask-image and box-decoration-break, in case you want to learn how to go about it and get some ideas on approaching any alternative methods. At the time of writing this article, it’s best to view that in Chrome.

Here’s another example that shows off how this effect might be used in a real-world context, revealing the text of different “tabs” as you navigate between tags.

For design variants, play with different colors, and number and kind of gradients. Let me know what you come up with!

I have seen compelling examples of ways to code that work with browser zoom that help make a site look nicer when high levels of zoom are applied. But they don’t fight against it.

You might say: but I zoomed my site in to 500% and it looks bad! It might, it’s true. But that’s just, like, your opinion, man. Zoom works consistently. People that use it know what it does. They know what to expect. They aren’t you, they might have a different approach an expectation than you do.

I wanted to write all that before I share this snippet. This is a variation of what someone sent me the other day as a way to size type that scales with the window:

html {
  --size-factor: (0.00188323 * 100vw);
  font-size: calc(12 * var(--size-factor));
}

Their version was a bit more exotic, incorporating different scaling numbers for pages in landscape vs. portrait and such. This has the effect of “fluid type” on a website, the bigger the window, the bigger the type, and vice versa. The magic number you see above there is essentially so that that you can multiply against it with reasonable numbers that maybe feel something close to pixel (px) numbers, 12px in this case. In that way, it’s a lot like the font-size: 62.5%; thing we used to see a lot such that the math works out that 1.2rem would be 12px (you can do it in your head easier). I’d suggest scrapping that thinking. Don’t think about font sizing in pixels at all — it isn’t useful.

What is ultimately going on here though is that the font-size is being set in viewpoint units only. This is what “fights” the browser zoom. I could have done html { font-size: 3vw; } and the effect would have been basically the same.

Bad news bears.

The advice: any time you are setting a font-size, it cannot only be viewport units. It has to factor in some other kind of unit. Heck, even px works to maintain some scaling. Even this freaks me out a little bit because it affects that rate of scaling and if you speed that up or slow that down too much, that’s also messing up with the natural exceptions of how zoom works.

The best approach that I know of is to use clamp() so that font-size can’t get too big or too small based on window size alone, then include a rem value (that’s somewhere in the vicinity of 1) in the calculation such that zooming still works normally.

See the Fluid Type Scale website for easy to generate snippets.

And this goes for using container units too!

Multiplexed typefaces (sometime alternately referred to as “duplexed” or “uniwidth”) maintain a consistent set width across at least one axis of variation, like weight, allowing for adjustments without causing text to reflow.

I was just playing with an idea around this recently and only after sharing an idea learned the proper terminology. Nick Sherman wrote about this and the article has this compelling demo:

I quite like that!

The reason I was having a play with it was I was watching Marques Brownlee’s review of the Rabbit R1 and noticed how the menu looks as you scroll through it:

You can see there that is kind of what is happening. The text is clearly getting bigger, yet the menu items above or below are not reflowed, they stay the same essential size. The text does get quite a bit bigger horizontally, so perhaps this doesn’t fit the definition of multiplexing, but it’s in the same ballpark.

I took a crack at it here:

I thought what I could do is use an HTML structure that includes an internal styling-only <span>, like:

<nav>
  <ul>
    <li>
      <a href="#">
        <span>Menu Item</span>

Then when the menu item is hovered over, I could to a scale transform on the <span> and have it not effect the natural height of the <a> parent. Which works great!

Then just to fiddle with variable fonts a smidge, I updated the font-variation-settings and animated them.

ul {
  font: 100% system-ui; /* on macs, yields San Franciso, which is variable */
  > li {
    > a {
      font-variation-settings: "wght" 600, "wdth" 100;
      &:hover,
      &:focus {
        font-variation-settings: "wght" 900, "wdth" 700;
        @media (prefers-reduced-motion: no-preference) {
          transition: scale 0.1s, font-variation-settings 0.1s;
        }
        span {
          display: block;
          scale: 1.33;
          transform-origin: left center;
        }
      }
    }
  }
}

I only put the transition on the hover/focus state on purpose. Normally that is a mistake, but here, I wanted the “off” transition to be instant and only do a smidge of morphing as the menu item becomes active.

But back to multiplexed fonts… some fonts are literally designed to allow this, like HEX Franklin:

You can see it isn’t totally perfect at all weights, but it’s pretty close! I just think that is so neat. If you’re using a font that has this ability, it would be a shame not to use it.

Check out Electric Blue as well, where the effect is a perfect multiplex, but less traditional:

Nick has some important notes:

On a related note, some variable fonts also offer a “grade” axis separate from (and often in addition to) the standard weight axis. This allows for multiplexed adjustments to a typeface’s apparent weight even if its standard weight axis would otherwise affect spacing.

Not all variable fonts offer multiplexed variations, but there is a growing selection available. And it’s worth noting that almost all monospaced variable fonts are naturally multiplexed.

On that first point, Roboto Flex is like that. It’s got a weight access that changes dimensions, but the GRAD axis does not.

This is my claim: we, as a civilization, forgot how to center things.

Centering things is almost trivial in CSS at this point. There are different approaches, because there are different situations. The knowledge to do so is pretty easy to find.

So something is clearly getting lost between know-how and applying that knowledge.

Clearly, as Nikita showcases many dozen examples of getting it wrong. Plus a fair point: sometimes weird font metrics are the culprit. The leading-trim property is going to be yet another excuse-buster.

I particularly like the Geometric Humanist stack:

font-family: Avenir, Montserrat, Corbel, 'URW Gothic', source-sans-pro, sans-serif;

Look at how nicely it renders across all the different major operating systems:

It’s also impressive to me that all the major operating systems ship some sort of handwriting font that is half decent.

Use text-wrap: balance; on headings and subheadings. And use text-wrap: pretty; on paragraphs of text to get rid of orphans on the last line. Despite the Chromium-only support, these would be a good candidate for progressive enhancement.

The performance impact is generally negligible but there in extreme conditions.