Standardista

CSS3, JavaScript and HTML5 explained

@font-face & browser support

Up to now, web developers were limited in what typography they could use on a website to what the client had installed in their environments. Now that we have finally convinced designers to not include any fonts outside of georgia, helvetica, arial, times roman, and a handful of others because of the awfulness of text images, @font-face allows us to retrain designers to use unique fonts, only if they have the legal right to post those fonts on the web.


What is @font-face

Generally, we’ve been limited to using the fonts pre-installed on MS Windows, Mac and Linux OSs. Increasing support of the CSS3 @font-face allows us to load a font onto our servers, link to and name that font in our CSS, and then use that font we’ve imported as if it were a native font in the client’s environment. With @font-face, we can worry less about what font our users have installed, and make our sites better match the intentions of our designers. @font-face enables you to provide your own font(s), @font-face eliminates the need to depend on the limited number of fonts users have installed on their computers

Browser Support for @font-face

CSS2 introduced @font-face. CSS2.1 killed it. CSS3 is reintroducing it. Why do you need to know the history? Because, it means there is actually a feature of CSS3 that internet explorer supports, albeit, differently than all other supporting browsers.

Because I am browser support table happy, here is the @font-face browser support table:

CSS Property IE6 IE7 IE8 Safari iPhone Chrome Firefox Opera
@font-face       3.2   4.0.249.78 3.5 10
format EOT EOT EOT TTF/OTF 3.1 supports SVG TTF/OTF support added 1/25/10
SVG supported by default
TTF/OTF TTF/OTF

* SVG is supported, but it’s a larger file size

Google Chrome and @font-face:

Google Chrome actually does support @font-face, but it was turned off by default until version 4.0.249.78 released on 1/25/20. Chrome has supporte SVG fonts for a while now.

While developers have been able to turn on @font-face support in Chrome in their own environment, only Chrome users who have updated to the January 25, 2010 release have it on by default. Google chrome users tend to be quick at updating, but stats don’t indicate the version number, so as of right now you can’t assume that Chrome has @font-face turned ON as the default settings for most users. Like with all site enhancement features, feel free to include fonts of type TTF/OTF, but make sure to pick a font backup that degrades nicely.

Note: Digging deeper, I found Becoming a font embedding master which both explains a link on where you can convert TTF2EOT so you can display similarly on IE than on good browsers (yeah, I said it) and exporting to SVG for font support on iPhone 3.1, Chrome 2 & 3, and 4 less than 4.0.249.78, and Opera 9 (your SVG font will work in Opera 10 and future versions of FF, Chrome, iPhone and Safari as well). Also check out FontSquirrel to convert your font files to differing formats (EOT, SVG, WOFF) for greater browser support. WOFF is a new format that Mozilla is hoping will become the browser standard. It is supported in FireFox only, as of FF3.6

Internet Explorer and @font-face:

Internet Explorer has been implementing @font-face support since version 4*. In any event, it is defintely supported in IE6, IE7 and IE8. However, their implementation relies on Embedded Open Type (.eot), a proprietary format, which no other browsers use. To make IE users happy (which some could argue you shouldn’t, as a method to encourage them to upgrade), import EOT fonts in addition to TTF/OTF fonts, and included them as "fall backs" in the font family declaration (discussed in @font-face implementation below) . FontSquirrel is a place where you can convert fonts you can legally distribute to EOT (and SVG) format.

* Note: Most people say original support of @font-face was IE5. I am not sure and I am not going to pull out my 286 to check. However, with a search, I found that IE4 had a few rendering issues, like not rendering anything on the page until the font was downloaded, so I am sticking with 4.

@font-face implementation

The syntax for the @font-face implemenation is:

@font-face {
  font-family: yourNameForTheFont; /* required */
  src: source;						/* required */
  font-weight: weight;				/* optional */
  font-style: style;				/* optional */
}

The font-family name can be anything you make up. I like to make it one word, for ease of entering it correctly as a value of the font-family property of a CSS selector later.

Declaring font-family source(s):

The source can take several formats. In addition, you can declare more than one source. If the browser doesn’t find the first source, it will go for the next source, and so on, until it either finds a source, or it runs out of sources. Example formats include:

@font-face {
     font-family: curlyQ;
     src: url('../fonts/makeUpSomethingElse.eot');
     src: local('Edwardian Script ITC'),
          url('../fonts/EdwrdScrpItc') format('opentype'),
          url('../fonts/GaelicWimsy') format('svg'),
          url(data:font/otf;base64,T1RUTMillIONsOfLETteRsInaROW12fAtGrrYUUUUBx);
}

In the above example, I’ve listed 5 sources. A bit excessive, but I wanted to explain those five components, so I made an excessive example.

The first declaration is for IE. IE ignores local, which is the first declaration in the second listing. In this way, IE only downloads what it needs and doesn’t download stuff it doesn’t understand.

Next I declare a font local to the user’s machine: local('Edwardian Script ITC')**. This looks for the font file locally on the site visitors computer. IE ignores local, which is great, since it will then ignore the other stuff it doesn’t understand. If you don’t have a local font style to declaration, it is OK. IE also doesn’t understand the multiple listings or the format, so as long as you include local, more than one declaration or a declaration with a format suggestions, IE will do o.k. IE will either ignore in the case of local, or misunderstand it, if there is a format or more than one declaration withing a property/value pair.

If your suggested format is incorrect, as long as the file is an understood format, it should work in Safari, Opera and Firefox.

The next example looks for a file in the SVG format. This is what you are feeding to Chrome and Opera 9.

The last example is a data example, cut way short. Actual fonts will have a few thousand characters. Similar to how you can include a data source for images, you can include them for fonts. TypeKit (described below) actually serves their fonts up in data format to Firefox and Safari, and serves EOT for IE.

**Note: Watch this page become the first google results for Edwardian Script. That would be funny. None of these examples are actually meant to work. I made the URLs and file names up.

Applying imported fonts with CSS selectors

Once the font is declared using the @font-face syntax, you can then refer to it as you would helvetica, arial, etc. Using the example above:

h3 {
    font-family: yourNameForTheFont, curlyQ, arial, helvetica, sans-serif;
}

Note that I have included two imported font family names. That is legal. Note that I have also included common fonts and a default font. That is HIGHLY recommended.

TypeKit

While the TypeKit website indicates support for Firefox 3.5+, Safari 3.4+ and all versions of IE, parsing the TypeKit javascript, they have support for the following browser engine versions:

Browser Type Version
Gecko 1.9.1
Safari 525.13
Chrome

4.249.4
supported by TypeKit.
Chrome has @font-face support turned off by default

IE 6.0
iPhone specifically excluded in Typekit
Opera not included in Typekit, though Opera Supports @font-face

However, I am reading obfuscated code, so I could be talking out of my tushy. I did test in those browsers (not necessarily those versions, but those browsers), and it works in all except iPhone.

The way TypeKit works is you join TypeKit, enter the domain you want to use TypeKit on (you’re only allowed one domain for the free version), and select the fonts you would like to enable for that domain. TypeKit provides you with a link to a script file and a javascript snippet to add to your document <head>. TypeKit also provides you with a class that you can add to elements that you want to have the font, and provides you with a snippet of CSS code for the font-family property that you can sprinkle your CSS with for selectors where you want to use the TypeKit font.

The TypeKit javascript that you attach to your code basically does a LOT of browser sniffing, and only serves up to Gecko, Safari (not iPhone), Chrome and IE6+. Since it is sniffing, it doesn’t serve up any CSS to browsers not in the sniffing. So, while Opera10 does support @font-face, TypeKit does not.

Microsoft WEFT

The Microsoft WEFT is a free utility to create linked font objects. WEFT font objects are compressed and are privately installed by IE in a way that is inaccessible to other applications on the computer and other websites. WEFT supports OpenType (OTF) and TrueType (TTF) fonts in TrueType (TTF) format.

Legalese

The main issue with @font-face is the ownership of the fonts. Make sure you are legally allowed to upload and share a font before using @font-face, as when you embed a font, that is what you are doing: sharing a file. Just like music, for most fonts it is illegal to upload and share without proper attribution and/or payment.

3 Responses to “@font-face & browser support”

  1. [...] Font face more deeply explained [...]

  2. When you say iPhone 3.1 supports SVG web fonts, do you mean the 3.1 version of iPhone OS, or the 3.1 version of Safari (which was on iOS 2)?

  3. browsers says:

    It’s really a cool and useful piece of info. I am glad that you simply shared this useful information with us. Please stay us informed like this. Thanks for sharing.

Leave a Reply