Even though the @font-face rule was born with the CSS2 spec in 1998, it took almost ten years for browser makers to start supporting it – with real, widespread support coming not until a couple of years later.

That is why people usually see it as part of CSS3.

This solution requires you to personally own the license of the fonts you want to use – and to upload them to your server. Being based on self-hosting, it can add to your space and bandwidth fee quite quickly.

But there's an easy solution to that: subsetting.

Subsetting is the practical aspect in owning the fonts: you can take the original font file (usually a .ttf or .otf) and slim it down to only the characters that you need, deleting the unused ones.

This can be done with font editing software, such as the free FontForge or the ultra-famous FontLab. On complex, more complete character map fonts this process brought them down to 50 kb, starting from 600 kb (with only the basic Latin map remaining, which is cool for mono-language, western-focused websites) – resolving the space and bandwidth issues.

This approach, while a cool and fast solution, can easily break your font license.

Since there are a multitude of them, both standard and custom ones from each studio and foundry, you may want to read them to be sure that the font you're using allows modification – and web usage, especially if only the desktop version exists.

Doing so can save you and your company from many lawsuits.

Generally, if you're working on desktop fonts you're not allowed to use them on the web (read your licenses carefully, some of them don't even allow editing of the font files); also, desktop fonts are optimized for print, so they won't render perfectly on the monitor. The best approach would be to purchase the web font directly – some of them even come bundled with the desktop one.

OK, you purchased the correct typeface, you subsetted it: all of the above is useful, but now what?

Now you need to write the code for your font to be addressed correctly by the browser.

The CSS declaration looks like this:

@font-face {
  font-family: "Font Family";
  src: url("font.eot");
  src: local(":)"),
    url("font.woff") format("woff"),
    url("font.otf") format("opentype"),
    url("font.svg#filename") format("svg");
  font-weight: normal;
  font-style: normal;
  }

Font family this time will address only our custom specified font – it's an open declaration, meaning you can define it as you want: exact name, all-caps, everything is permitted – even renaming Helvetica to Arial and vice versa.

How evil is that?

Not to worry, just keep it consistent and it will be OK.

What really stand out are the different formats. We named (and are used to) only the .otf here – so what are the others?

The Web Open Font Format (WOFF) is a want-to-be worldwide standard format for the fonts on the web, even praised and pushed by the W3C; it contains the TrueType font plus other metadata in a package that is generally compressed by a mighty 40 percent respectful of the original file. It's supported by all major browsers but at different levels, so it still has a long road till it becomes standard.

Despite that, WOFF2 is already out: it features a better, lighter compression than its older brother.

SVG stands for Scalable Vector Graphics – it's the standard for readable vectors on the web, since every shape is defined by XML values.

It will just contain and treat every character of the font as a vector, described by various coordinates and values; it weighs less than the original font file – and it can contain multiple fonts in one file! Unfortunately, support is still inconsistent, especially (as always) on Internet Explorer. Way to go, Microsoft!

Also, SVG still doesn't support letter-spacing and hinting – hey, what's that? Don't worry, we'll explain it in later chapters.

Despite that, it's still the most supported custom font solution in mobile browsers on iPhone and iPad, for example. So it's inclusion is mandatory.

EOT (short for Embedded OpenType), is a Microsoft proprietary format – yes, you read that right – which is in use only by Internet Explorer. Made in the late nineties, it is a compressed OpenType which also embeds a domain-locking functionality, (it's optional to turn it on), meaning that the specific font can be used only on that domain, preventing it from being stolen.

It was pushed to enter the W3C declarations as a standard web font – and it was twice refused, lastly in favor of the .woff format.

Despite that, Microsoft still use and require it for its browsers – obligating every Web Designer to incorporate it in their works.

When it comes to its implementation and declaration within the font-face rule – and to avoid the IE bug above, which will make the browser go back to web-safe fonts, we must name the EOT format first, declaring it in a separate source property from the others. Things will go pretty simple this way.

IE will read your declaration and request for specific fonts. If it encounters a format it doesn't recognize and use – it will download it anyway (adding HTTP requests and bandwidth usage), then won't understand it, causing it to completely ignore the @font-face rule – and ruining your crafted design through the use of web safe fonts.

Way to go, Microsoft: Part II.

Another problem with the standard rule and IE is the fact that this specific browser will jump to the last source property available – writing its declaration separately will allow us to stop exactly at its own font, saving time, bandwidth, and problems.

From there, it is all pretty standard, with a format declaration and a URL for each font file: every other browser will ignore what doesn't belong to it and search for its own compatible format.

Even being two different styles of the same typeface, since they are incorporated into different fonts from the regular, we must declare them as different typefaces.

If your font has those styles defined, then you can remove the font-weight and font-style properties from the first declaration, since you won't need them.

You could easily use them for those styles, logically.

The first declaration, aimed at the italic weight would look like this:

@font-face {
  font-family: "Font Family";
  font-style: italic;
  font-weight: normal;
  src: url("fontItalic.eot");
  src: local(":)"),
    url("fontItalic.woff") format("woff"),
    url("fontItalic.otf") format("opentype"),
    url("fontItalic.svg#filename") format("svg");
  }

Here, the same declared typeface name is used with different weights built within. This would mean that using standard em objects within your site will make the CSS automatically call the italic version of your Typeface, even when using and declaring one single name.

Everything is simple, logical, and beautiful.

Unfortunately, for a long time Internet Explorer didn't understand this specific, style-linking declaration, rendering always only the regular font. (Opera also used to have one bug related to this in 10 specific versions, but it's long gone.)

For this reason, a different declaration needed to be made. Way to go, Microsoft: Part III.

OK, break over; time to get back to work! This is the declaration that was meant to work:

@font-face {
  font-family: "Italic Font Family";
  src: url("fontItalic.eot");
  src: local(":)"),
    url("fontItalic.woff") format("woff"),
    url("fontItalic.otf") format("opentype"),
    url("fontItalic.svg#filename") format("svg");
  }

The application of all the above is pretty straightforward. Let's assume you want your website to be written in the fictional "Cool font".

There is nothing simpler than writing your CSS this way:

html { font-family: "Cool Font", Georgia, serif; }

@font-face {
  font-family: "Cool Font";
  src: url("font.eot");
  src: local(":)"),
    url("font.woff") format("woff"),
    url("font.otf") format("opentype"),
    url("font.svg#filename") format("svg");
  font-wight: normal;
  font-style: normal;
  }

A different font with a different declaration for your headings – and you are good to go!

All the previous declarations are correct and meant to work. But still, even with the last solution, there are a variety of problems – and will always be, since we want our design to be as backward compatible as possible (ignoring old browsers is never a good solution).

For example, the second solution will make the text render correctly on IE – but on Mac OS X and iPad Safari it will give birth to another phenomenon: double-bolds and double-italics.

This means that on top of the correct bold and italic, the browser will apply faux ones.

And this is just one of the problems – on a specific OS. But there are sadly more, shared ones on an approach that it widely used, like crashes on some systems and so on.

To be honest, I found the following writing more acceptable, compatible, and with more pros.

So, why didn't I give you it from the start? To illustrate what you'll find more frequently on the net, in tutorials – and the errors that it gives.

I usually prefer to load each font with a different name, with the correct style and weight applied individually.

Yes, I too, hate to have to remember each name – but the "same name family" solution presents some problems on IE (again…) like the fact that you can't apply more than four properties to the same family – this could be forgiven, after all I don't think I will use all the normal, italic, bold, bold-italic styles on the same font on the web (but you never really know) – but this definition makes the browser on the iPad 1 crash 100% of the time too, so…

It's time for a new, better one that is a mix of the above:

@font-face {
  font-family: "Cool Font";
  src: url("font.eot");
  src: local(":)"),
    url("font.woff") format("woff"),
    url("font.otf") format("opentype"),
    url("font.svg#filename") format("svg");
  font-weight: 400;
  font-style: normal;
  }

@font-face { 
  font-family: "Cool Font Italic";
  src: url("fontItalic.eot");
  src: local(":)"),
    url("fontItalic.woff") format("woff"),
    url("fontItalic.otf") format("opentype"),
    url("fontItalic.svg#filename") format("svg");
  font-weight: 400;
  font-style: italic;
  }

@font-face { 
  font-family: "Cool Font Bold";
  src: url("fontBold.eot");
  src: local(":)"),
    url("fontBold.woff") format("woff"),
    url("fontBold.otf") format("opentype"),
    url("fontBold.svg#filename") format("svg");
  font-weight: 700;
  font-style: normal;
  }

Using this method, it's a little bit longer – since you need to address each name separately and to pay attention while setting the exact font-weight, but it's worthy: each style will work perfectly on every browser, even allowing for more than four styles in the same type family in IE.

Doing an extra step and applying the same weight and style in our elements, not only in the @font-face rule, will allow the text to be beautifully styled, even if the desired custom font won't load for any reason, also removing any risk of faux or double styles.