Skip to main content

Build Using fonts

Using fonts

By Jonathan Stening

Using fonts

Currently around 70% of websites use custom fonts; made popular in late 2008 when Safari and Chrome finally joined Internet Explorer and added @font-face support.

This feature was hugely popular with designers, who could now be more expressive with their typography; other web browsers soon followed and ‘web fonts’ became a thing.

Note: Microsoft were actually first to implement web fonts back in 1997 when they added @font-face support in IE 4, based on the CSS2 Fonts Working Draft. The CSS2 Fonts Recommendation wasn’t released until the following year, but it wasn’t until 10 years later in late 2008 when Safari and Chrome came to the party and popularised the feature as we know it today.

In this article

Introduction

Implementing fonts today is generally pretty straight forward, but it’s important we provide some guidelines for how we expect the basics to be implemented when using the GUI Framework. In this article I’ll cover some of the more technical aspects of implementing fonts, and provide some good great insight and storytelling along the way.

There are two main areas we’ll cover regarding fonts in the GUI Framework: considering ‘desktop’ fonts use for designers and the implementation of fonts for developers. This article is aimed at both web professionals but will mostly cover the latter. For a more in-depth read on the typography system see Typography.

Note: What we commonly refer to as a ‘font’ is often more correctly a ‘typeface’, but within digital and for the sake of brevity I’ll be using ‘font’. This article is about implementing digital fonts and we can generally consider a font a ‘font file’. But for the traditionalists, typography professionals, especially those with OCD, fonts and typefaces are quite different. For those interested check out What’s the difference between a font and a typeface? and Typeface vs. Font: Terminology Smackdown.

A historical view

Back then: System fonts

Once upon a time web browsers could not render specific fonts. The fonts a website used were limited to those installed on a user’s machine, often referred to as ‘system fonts’. Web professionals relied solely on ‘font stacks’; a list of system font names they would define in order of preference to implement their typography. They would then cross their fingers and hope for the best. The user’s machine would run through the list of fonts names until it came across a font it recognised and rendered.

‘Web safe fonts’ became a thing because while web professionals didn’t know exactly which fonts were installed on their user’s machines, they knew some fonts were more commonly installed than others. They could design interfaces with this in mind, roughly estimating the typography enough to convey the look and feel they required.

A very simple and common web safe font stack for example is ‘Arial, “Helvetica Neue”, Helvetica, sans-serif’. A website using this stack will generally use Arial on a Windows PC, Helvetica Neue or Helvetica on a Mac and if neither are found will use a generic-family font; a built-in font chosen by the web browser, in this case a ‘sans-serif’ font.

This system font stack approach is still used today and actually has a number of advantages. We’ll get into that a little later.

This is now: Web fonts

Web professionals still use the above approach, it’s still valid and very important to list fallback fonts in a font stack — except now in addition they can specify the exact the fonts they require.

Implementing web fonts involves uploading the font files to the web server; the specific fonts, file location and other settings are defined within a CSS @font-face at-rule.

When visiting a website using web fonts, the user’s browser will request the font file from the server, load it into the memory, cache and utilise it for that website — rendering typography as intended.

You can read more about Implementation below.

How does licensing work?

As with all fonts, whether used for design or as a web font, fonts are hand-crafted. Much like with music, an artist produces a font set; painstakingly designing each character (or ‘glyph’) with incredible attention to detail in order to produce the desired result. We have to pay these artists for their work. Like dur!

Font foundries

Font licensing and purchase is generally looked after by font ‘foundries’. There are many foundries out there.

Some typefaces are only available at one foundry, while others are readily available at many foundries. Confusingly some common typefaces are available at many foundries but are slightly different in appearance; different in font (see note above). For example Garamond, a ~400-year-old typeface is available as ‘Adobe Garamond Pro’ from Adobe, and ‘ITC Garamond’ from ITC. Both are Garamond by typeface, but different by font. There are many different Garamond fonts! See figure 1 below.

It’s really important to keep the above in mind before getting out the boss’ credit card and committing to purchase fonts.

Figure 1: Garamond fonts (ref Typeface vs. Font: Terminology Smackdown)

Licensing fonts for designers

Fonts for designers are often referred to as ‘desktop’ fonts and licensing these fonts is pretty straight forward. Generally designers purchase the font files and install them on their machines.

Often designers share these files with their designer colleagues but this is not advised; unless the licence includes organisation use, or you like living on the edge and/or spending a whole lot of money, or time living away from home unnecessarily. Don’t do it.

Licensing fonts for developers

Licensing fonts for developers is a little trickier because users request the actual font files, which in turn end up on their machines in their web browser’s memory. Font foundries are funny about this.

Cloud-based hosting

Foundries provide web fonts a number of different ways; most commonly by use of their many cloud-based hosting subsidiaries, such as Adobe Typekit, Myfonts.com or Fonts.com. These services often charge per impression; each time the font file is requested online by your users.

There are also free cloud-based font hosts, such as Google Fonts. While these methods can be great for prototyping, they are generally not recommended for production and not appropriate for use with the GUI Framework.

Self-hosted

The other method is to obtain a full-rights licence from a foundry where the various font files are downloadable and self-hosted; effectively purchasing ownership of the fonts for use as per the licence terms.

At Westpac our web fonts are licensed for use across the organisation. Each GUI specifies its own font and settings, as approved by the organisation’s Brand Dept.

The majority of our brands use a specific web font as their ‘brand font’ and all use a simple system font stack as their ‘body font’. System font stacks are great for general body copy; they’re simple, legible, quick to load and require less overhead. You can learn read more about brand and body fonts in Typography.

How do I get the font files?

Due to licensing restrictions we are unable to publicly distribute fonts. Soz.

Fonts files for designers

Generally as a designer at Westpac the desktop fonts you require will be pre-installed on your machine. If this is not the case please speak to your project lead who will point you in the right direction.

Fonts files for developers

For those who work at Westpac we provide an internal link to the font files required by your particular blend; simply follow the download link in the your blend’s index page. All versioned web font packages are available on the internal network.

It is still very important that you check to ensure the fonts you’ve obtained are licensed for your particular use case.

Implementation

Formats

Just when you thought you had it all, there are a few gotchas. While less of an issue now with web browsers regularly updating to support new features and formats, if you need to cover legacy browsers (e.g. IE8+ and older iOS devices) you’ll need to provide a number of font file formats. The GUI Framework includes each of these formats for maximum browser compatibility.

  • EOT (Embedded Open Type) – IE6–IE8
  • WOFF (Web Open Font Format) – Modern browsers
  • WOFF2 (Web Open Font Format v2.0) – Super modern browsers
  • TTF (True Type Font) – Safari, Android, iOS
  • SVG (Scalable Vector Format) – Legacy iOS

Installation

The various font files need to be saved somewhere. Within the GUI Framework make sure you install the files into the assets/font/ folder of your blend, as specified by the @font-face at-rule settings found in your blend’s gui.css.

The @font-face at-rule

Let’s take a look at the @font-face at-rule from the St.George GUI as an example...

@font-face {
  font-family: 'dragonbold';
  src: url('../font/dragonbold-bold-webfont.eot');
  src: url('../font/dragonbold-bold-webfont.eot?#iefix') format('embedded-opentype'),
    url('../font/dragonbold-bold-webfont.woff2') format('woff2'),
    url('../font/dragonbold-bold-webfont.woff') format('woff'),
    url('../font/dragonbold-bold-webfont.ttf') format('truetype'),
    url('../font/dragonbold-bold-webfont.svg#dragon_boldbold') format('svg');
  font-weight: normal;
  font-style: normal;
}

Here you can see the @font-face rule defining a number of different font settings:

  • Font family: the font-family name is used within the CSS to refer to this particular typeface; ‘Dragonbold’ in this case
  • Formats: the different formats and file locations are defined to provide adequate cross-browser support; EOT, WOFF, WOFF2, TTF and SVG (as mentioned above)
  • Font weight: the font-weight is used to set the default weight for this font declaration; ‘normal’ in this case (but could be 100, 300, 400, 500, or bold etc.). See Style linking below.
  • Font style: the font-style is used to set the default style for this font declaration; ‘normal’ in this case (but could be italic etc.)

Style linking

There are a number of different ways to implement font styles and weights; each have their pros and cons. The GUI Framework utilises Style linking, but you can read about other methods at How To Set Weights And Styles With The @font-face Declaration.

Style linking is a method which allows you to neatly group your typeface fonts and utilise the same font-family name to refer them. The alternative is to give each font its own font-family name; but this can be cumbersome.

Let’s take a look at the @font-face at-rule from the BankSA GUI as an example...

/* Aller Bold - linked as font-weight 'normal' */
@font-face {
  font-family: 'aller';
  src: url('../font/Aller_Bd.eot');
  src: url('../font/Aller_Bd.eot?#iefix') format('embedded-opentype'),
    url('../font/Aller_Bd.woff2') format('woff2'),
    url('../font/Aller_Bd.woff') format('woff'),
    url('../font/Aller_Bd.ttf') format('truetype'),
    url('../font/Aller_Bd.svg#Aller-Bold') format('svg');
  font-weight: normal;
  font-style: normal;
}

/* Aller Light - linked as font-weight '300' (light)  */
@font-face {
  font-family: 'aller'; /* same as above */
  src: url('../font/Aller_Lt.eot');
  src: url('../font/Aller_Lt.eot?#iefix') format('embedded-opentype'),
    url('../font/Aller_Lt.woff2') format('woff2'),
    url('../font/Aller_Lt.woff') format('woff'),
    url('../font/Aller_Lt.ttf') format('truetype'),
    url('../font/Aller_Lt.svg#Aller-Light') format('svg');
  font-weight: 300;
  font-style: normal;
}

@brand-fontfamily: 'aller'; /* Less variable */

If you refer to the example code above, note the font-weight and font-style settings inside the @font-face at-rule. By utilising these two settings you can have multiple @font-face declarations and set the appropriate weight or style for each of the fonts, all tied together with the same typeface font-family name.

Then in CSS you simply use the standard CSS font-style and font-weight properties as per normal and the browser will use the correct font file you’ve specified. For this example I’ll refer to the Less variable we created above as this is how it should be implemented.

.heading {
  font-family: @brand-fontfamily;
}
.heading-light {
  font-family: @brand-fontfamily;
  font-weight: 300;
}

Note: in the example above we set both font-weight and font-style for the brand font as being normal, resetting each even though our brand font is in fact bold. In this way when we refer to ‘font-family: aller’ in CSS we don’t need to also specify ‘font-weight: bold’ to access it. The font will automatically render bold just as the font was designed. This approach is used in the GUI Framework as the brand font is usually a bold font, mostly used for headings.

Faux-bold

Browsers will force any font to be bold or italic etc. if it has to. If the font you are ‘bolding’ is a system font, it’s likely the style is appropriately linked to the bold font within the larger font set installed on a user’s machine. However, if the font is a web font provided by the server you need to do this style linking yourself within the @font-face at-rule. See Style linking above.

If you haven’t linked your fonts correctly you will get what’s referred to as ‘faux-bold’; where the browser tries to help out by faking the characters, thickening the glyphs to appear bold-like. The issue with this is the results are not consistent across browsers and your users may have to deal with reading illegible text.

The bold font for your typeface should be shown as per how the typographer intended it to be shown. Don’t mess with typographers!

You can read more at Say No to Faux Bold.

Web font drawbacks

Like with everything, there are drawbacks. The following are a number of drawbacks with using webfonts.

  • Inconsistency – Fonts are rendered slightly differently between browsers and operating systems. While they’re a lot more consistent than system font stacks, they’re not 100% accurate. Read more at The problem with web fonts.
  • Rendering speed – Since the user’s browser has to request the font files from the web server, it can take some time for the browser to have the files it needs to render the text. Especially on slow connections and when multiple fonts are required. Web fonts add extra overhead, perceived performance issues and FOIT.
  • FOIT – Most browsers will wait to render text until the necessary font files are available, often resulting in the ghastly ‘Flash of invisible text’. There are a number of ways to deal with this I wont be covering in this article. Read more about this phenomenon at A historical look at FOUT and FOIT and FOUT, FOIT, FOFT.

It’s important to be aware of these factors and if possible limit the use of web fonts in your web site or application. The majority of users prefer a simple legible font to enjoy reading, over a font-heavy interface they have to wait to ‘experience’. Quote marks intended.

Resources – All versioned web font packages are available on the internal network.