mindgarden

I just came across Simon Foster’s dingbat love story demo page. It shows how dingbat fonts can be used with @font-face to create a graphic design basically using just fonts and clever positioning.

More and more people are using dingbat web fonts for things like this. And while visually this is a great example there is a big problem semantically with this approach.

Looking at the page with CSS turned off it becomes very obvious:

The icons that the dingbat font contains are randomly mapped to letters. So when the visual presentation is taken away all that’s left is a string of random letters devoid of any meaning.

I’ve been thinking about this for a while and Simon’s example just was a good example to use for a blog post. By no means am I trying to pick on him individually as he’s a great designer. I’m aware that his page is a proof of concept on not really a real website.

But using this technique is problematic in terms of accessibility, SEO considerations and general semantics. Using WAI ARIA there is a role=”presentation” that should make the use of dingbat fonts less harmful to assistive technologies. But it doesn’t give back any meaning lost and WAI ARIA is not supported by all screenreaders yet.

And sticking with our example for search engines and other text based user agents the love story will simply be “qMpRRRRRRFwMJpFJpeMsrFttMppprFpppypMFuBBB”

[Update:] When searching for the string “qMpRRRRRRFwMJpFJpeMsrFttMppprFpppypMFuBBB” you actually get the dingbat love story as the search result: http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=qMpRRRRRRFwMJpFJpeMsrFttMppprFpppypMFuBBB&qscrl=1

I’m getting more and more excited recently about the possibilities CSS 3 offers in combination with web fonts. There are a lot of cool demos floating about out there on the web, so I created a tumblr blog on which I’ll try to link to the noteworthy ones.

It’s not about linking to websites using beautiful type and typography, I leave that to others. This one is more about what you can do from a technical perspective. Often this will result in something beautiful too, but it’s more about demos rather than real websites.

The blog lives at webfontgallery.com

This is the associated twitter account where posts will show up too: @webfontgallery

The first german Webfontday will take place on November 13th in Munich. The Typographische Gesellschaft München is organizing the event:

Die tgm hat zahlreiche namhafte Experten eingeladen, um die erste Konferenz zum Thema »Webfonts« auszurichten. Einen Tag lang werden Sie Gelegenheit haben, wertvolle Einblicke rund um das Thema zu sammeln. Die Bandbreite der Vorträge wird dabei sowohl technische als auch gestalterische Fragestellungen berücksichtigen, eine Podiumsdiskussion bietet das nötige Diskussionsforum.

( english translation )

I’m having the honor to represent the Google Web Font team and to do a presentation about the Google Font Directory. This is the first conference that I’m aware of that is dedicated exclusively to web fonts and other speakers include Bryan Mason of typekit.com and Jörg Schweinsberg of Linotype.

Sign up here: http://www.webfontday.de/content/anmeldung

Oh, and If you want to keep track of the latest news about the Font Directory we’ve just launched the web font blog here: http://googlewebfonts.blogspot.com/

Someone in the comments on one of my posts about the Google Font API was asking:

To be honest I still do not understand why should I use Google if I can embed a font myself with just a few lines of CSS. Where is the big benefit? Speed and reliability of the server I won’t let count. (translated into english from german)

That’s a valuable question that I thought would be good to answer. So here we go.

Licensing

One of the big issues with webfonts still is licensing. If you host a font file yourself you have to really make sure that you have the rights to do so. And the responsibility is entirely up to you. Using the fonts in the fonts api you don’t have to worry about these things as they’re all open source.

Quality

Our approach with the font directory is quality over quantity. While we will be growing the number of fonts in the directory we will make sure that fonts are suitable to be used as webfonts across the supported browsers. There were some issues with the rendering on Windows when the api launched but the api can be updated with improved versions whenever necessary which means the api will always deliver the latest and most optimised version to the browser.

While shoving a font file on your own server and writing a few lines of code might be something you can do quickly, testing the font in all the browsers and OSes is not. The font api team takes care of that for you.

Less code & hassle

In theory @font-face is easy to use. In reality there are quite a few gotchas. Plus browsers expect to be fed different font formats. You need to have an SVG version for iPads (which are now supported), EOT for IE and TTF for other browsers. Webfonts for the Android browser and printing of webfonts in Chrome/Windows can be tricky. You need to get the syntax right so it works everywhere at the same time too.

The font api we tries to take care of all of that for you. You add one line of code and it deals with all the complexity in the background.

Caching

The more popular the fonts in the Google font api become, the more likely it is that users of your website already have the font cached in their browser when they get to your website. The Droid font is already used by the Government of Chile and Smashing Magazine to just name two examples. And you can expect that to increase in the future.

So if a user has been to one of those websites earlier he has to do no downloading of any font files on your page.

Webfonts landscape

For the initial launch of the font directory it relied mainly on fonts that have already been around before. But by giving font designers the opportunity to be part of the directory it this encouraged them to improve the quality of their fonts when used as webfonts and also in general. The hope is also hope to inspire more font designers to create quality fonts that otherwise wouldn’t be there and for them to have a platform.

All that said there’s nothing wrong with hosting webfonts on your own server, in a lot of occasions it just might be a lot more convenient to use the api. Also, a lot of the benefits listed above apply to other font services too and if you’re looking for a specific font that is not available under an open source license it might be worth checking them out, too.

After last week’s HTML5 session video from Google IO now the video from the session in which the font API was originally released is online. The session was called “Bringing Google to your site” and webfonts are featured from minute 37:30