At long last it’s finally practical to use more than the traditional “web-safe” fonts on the websites you design. Sure, there were options going back several years, but we’re emphasizing “practical”.
One of the complexities that still remains with web fonts is the lack of standard licensing language from all type foundries. With that in mind we’re currently recommending that our clients “rent” their licenses from services such as Typekit.
What Typekit allows is a removal of the complexities of purchasing and licensing a type face from a foundry, and the complexity of hosting the font on your webserver – Typekit hosts it. If you ever “move” your website to another provider or server, you don’t need to move the font as well.
But there are some drawbacks of the possibility of using fonts:
- The standard web-safe fonts we’ve been using for years were designed for the screen, while many common fonts were never optimized for the screen.
- Different operations systems and browsers render fonts with varying degrees of quality.
- When you start using transparencies in your design, you’ll see various behaviours across platforms and browsers.
This is typical of the evolving capabilities of the browser market, and leads to a common-sense conclusion, which is:
Early in your design process, engage your technical team to create a sample mock-up of your preferred font, and view it in all common browsers and platforms before submitting to the client for approval.
If you simply design using desktop creative tools (Photoshop, Illustrator, etc.) without consideration as to how the design will translate to the web, you might be creating a lot of work for the technical team downstream, or putting yourself at risk of having to rejig the design after it has been approved.
The evolution of fonts on the web
Dynamic image generation
We started with dynamic image conversion, converting text strings into images of words in a specified font. The drawback here was primarily controlling the boundaries on fonts that are not fixed-width (monospaced). Different characters and different fonts were different widths, and most designs only allowed for an image of a certain size. Unless this was done manually, and previewed, there were problems.
Additionally, search engines can’t read words embedded in images, so this tactic was a hindrance for SEO.
Flash
Then sIFR (scalable Inman Flash Replacement) came along, but it required Flash, and certainly wasn’t ideal for some applications. As well, because the earlier versions of sIFR didn’t support CSS, it became labour-intensive to make changes to the font size, colour, etc.
JavaScript
The first JavaScript libraries that could load a font from a server and download them to a user’s machine appeared years ago – but there were drawbacks. Primarily, the complexities of licensing, and (obviously) that they require JavaScript. This might not be that large an obstacle, as most modern websites leverage JavaScript so extensively they wouldn’t function without it.
Font Face tag
The Font Face tag has been supported to some degree by most browsers for years. That said, it requires a lot of work-arounds to render a font seamlessly across common platforms. Used in CSS the syntax looks like:
@font-face {
font-family: “FONT NAME”;
src: url(“http://www.example123.com/fonts/font-name”)
}
The other challenge we face is the complexity of navigating the licensing agreements with different font foundry companies and factions.
New services: Typekit, Cufón and other services
Due to the state of the industry right now, we favour Typekit. It’s incredibly simple to sign up, browse the library, and start using new type faces on your website in a manner of minutes, and the process and licensing are straightforward. And because you’re renting the service, as soon as the foundries get their act together and the browsers standardize on their rendering of fonts, we can migrate back to the Font Face tag.
Typekit also provides a huge library of screenshots that demonstrate how the various faces will actually look in each major browser. Additionally, they provide tutorials for developers that teach you how to “degrade” to CSS and font face if needed.
For various reasons, we might decide to use other methods than Typekit, or competing services such as Fontdeck or Fonts.com, but for the vast majority of your projects, Typekit might be the best fit.
A few other considerations
- Screen resolution – to render well, type size should be no less than 10 pixels.
- Financial tables – don’t expect that what worked in print will work in HTML. For one thing, you are usually converting from a portrait to a landscape format, requiring an appropriate redesign. And you are limited in how small you can make the type for elements like column headers. Use the most complex table to design a new worst-case template.
- Footnotes, disclaimers, etc. – don’t go too small or the type will degrade on screen; redesign accordingly or consider making them interactive links, opening up pop-ups to display the content on mouseover.
Resources
- TypeKit – implement web fonts on your site
- TypeStage – implement Arabic web fonts (Arabic, Urdu and Persian) on your site
