Custom axes are defined by typeface
designers, can be any kind of variation
and only require a four-letter identifier
within the font file, which can be referred
to in CSS.Using a registered axis
When it comes to a registered axis, we
want to make sure we are using any
associated CSS properties, for example,
font-weight or font-style.
We can set up our fonts using the
@font-face at-rule as we normally would;
the change is in how we define the
variations for descriptors like font-weight,
font-stretch and font-style. Previously we
would have set a font-weight of 200 and
defined this as the light version of the
font, we’d then set up another font face
block for the bold version and the regular
version until we had all the weights
that were required for the design. With
variable fonts, we only need a single fontweights exist individually as a standard
font, which they don’t.
If we remove the fonts that don’t exist
as a standard font, the combined file
size is still nearly three times the size of
the variable font and with significantly
fewer styles. Even if you just wanted the
bold and regular versions, common in
many web projects, two versions of the
standard Source Sans Pro font are still
larger than a single variable font. What
this demonstrates is that we have the
potential to make massive savings on
bandwidth without compromising our
designs and creativity.
What’s more is that with just a single
file needed for the variation in style, we
only need one network request for all
weights and styles of a font and even
though we have technologies like HTTP/2
reducing network overhead, this is still a
major performance advantage, especially
when combined with improved font
compression formats like WOOF 2.0,
which will further compress file sizes. By
combining these technologies, bandwidth
and performance issues start to become
less of a problem.Banish layout shifting
As variable fonts become more widely
supported across operating systems, we
can look to improve performance further
by using a variable system font as a
fallback in our font stack. As things stand
right now, when we swap between our
fallback font and a custom font, we often
have to deal with effects like Flash of
Unstyled Text (FOUT) and layout shifting;
where the page janks and moves as the
fonts are loaded and then swapped within
the page.
At the moment, we can modify the
line-height, size and letter spacing to
try and match our system and custom
fonts to reduce that layout shifting.
Take a second to imagine if we had a
collection of variable fonts, built right
in the operating system – we could
modify things like x-height, width,
weight or other axes, changing the size
of the font itself to create an even closer
or perfect match to our custom font in
size and width. This would result in a
smooth transition between the two fonts,meaning less FOUT and redraw. If we
combined variable fonts with existing
CSS properties like font-display, we might
even get to a point where fonts will never
cause layout shifting again.Using variable fonts
Using variable fonts in our CSS is very
similar to how we would normally
use fonts on the web; using the @font-
face at-rule. However, we first need to
understand the different types of axes
inside a variable font as this determines
which CSS properties we make use of.
There are two types of axes in a
variable font: a registered axis and a
custom axis. A registered axis refers to an
axis that is common enough that it was
worth standardising. There are currently
five registered axes; weight, width, slant,
italic and optical size and these are often
mapped to existing CSS properties, such
as font-weight.FEATURES
Variable fonts