Before wide browser support for the CSS @font-face rule, web pages were limited to “browser safe fonts.” This meant the designer was constrained to using fonts that were available on every visitor’s machine. @font-face allows a web designer to make typeface decisions based on aesthetics rather than availability.
All modern browsers now support web fonts, in some form. Microsoft Internet Explorer has supported @font-face since 1997 in version 4, Apple Safari implemented support in 2008 in version 3.1, Mozilla Firefox added support in 2009 in version 3.5, and Google Chrome added support in 2010 in version 6.
Adobe BrowserLab has full support for @font-face. BrowserLab can help you ensure your @font-face declarations are working across multiple browsers. By giving you the ability to quickly test your @font-face declaration across target browsers, you can move on to designing the rest of your site. Give BrowserLab a try with your web fonts enabled pages.
When using @font-face you need to be aware of supported font formats and browser specific syntax. There is currently no universally supported web font format. Failing to provide proper font formats and browser supported CSS will result in your page rendering inconsistently across browsers. If done incorrectly, visitors will see the browser’s default font instead of the specified font.
There are some great font services that take care of cross browser support by dynamically generating the appropriate CSS for each browser. Typekit, Webtype, WebINK, and Fonts.com are some of the services available, and all of them generally take care of hosting and licensing. Using one of these services allows the quickest path to implementation without having to know too much about the underlying technology. Typekit provides many fonts created by Adobe, and we are working together to offer more Adobe fonts in the future.
If you find yourself needing to roll your own web fonts, there are a few basics that are required to ensure your intended fonts show up on all browsers:
First, and most importantly: Ensure your font license allows you to use a font on the web. Many foundries do not permit the use of their desktop fonts on the web. For more information, check out the Adobe Type blog on this subject.
Know your font formats. There are a few different versions of web fonts in use today.
- Embedded OpenType (.eot) – Supported by Internet Explorer only.
- TrueType/OpenType (.ttf/.otf) – Supported by the widest range of browsers, but, not supported in Internet Explorer. (this may change in IE9)
- Web Open Font Format (.woff) – Supported in recent versions of Chrome, Firefox and Internet Explorer, but not yet supported in Safari.
In addition to needing to worry about licenses and multiple font formats, browsers interpret CSS code differently, so writing a rule to include your fonts is less than straightforward. “Bulletproof” syntax for @font-face has evolved over the years to work around browser inconsistencies. Much of the syntax seems repetitive and counter intuitive. For a good history of @font-face and a clear explanation of the CSS syntax read the ”The New Bulletproof @Font-Face Syntax” blog post at Fontspring. Learning how the syntax has evolved gives a clearer picture of how each browser handles @font-face.
FontSquirrel is a web service that will convert fonts for you and generate CSS code. After uploading your fonts, FontSquirrel will convert your fonts for cross browser usage and generate CSS for you. The CSS code generated by FontSquirrel also happens to work just about everywhere, including mobile devices. If you use FontSquirrel to generate web fonts, make sure you have the proper license to do so.
I hope this brief introduction to web fonts has been helpful, and that you find BrowserLab to be a useful tool in helping you test your pages with web fonts.
Shout out to Paul Irish, Christopher Slye on the Adobe Type team, and Fontspring for their help and insight on web fonts.
Adobe BrowserLab Software Engineer