.mindgarden is the digital playground of marc tobias kunisch

.opinions on this website are in not necessarily those of my employer

.send an email to info 'at' mindgarden 'dot' de

.follow the mindgarden on twitter @mindgarden_de or @tobestobs
.occasional guest bloggers are @lwsrc, @dheeva and @idrathernot


Webfontday in München

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/


On Problems

I was part of a discussion with an esteemed friend of mine recently. My argument being that responsive design is great and that we should consider using it on our own pages.

His view of things was that as long as there is no problem with how we currently do things then we shouldn’t come up with a solution.

This premise that every change in how we do things needs to be triggered by a problem that needs solving to me is a very depressing thought. Of course it’s very easy to come up with all kinds of problems that suit pretty much any solution (to stay in the terminology). But I don’t think that is what he has in mind as he probably wouldn’t let “pages as we build them now are not as good as they could be” count.

Where my philosophy differs is that things do not have to be broken in order to try to make them better. I don’t think Mercedes would claim there is a problem with their cars. Still they aim to make them better with every iteration. The same should be the case for the web sites we build.

When I sit down to build a website I try to build the best website possible. That’s called quality. Good enough is boring. I don’t think I’d be doing what I’m doing if my professional life would consist of waiting for problems to arise and then fix them.

What’s great about what I’m doing is that there’s inspiration all the time. Sometimes it’s almost too much. Things are moving and getting better. And technologies are still evolving in a medium that’s still in it’s early days. People are coming up with new techniques all the time. Some are useless. Some are just not a good idea (why would I want to build an iPhone icon with CSS for example?). But it is good this is happening because inbetween there are great ones. This makes the web better in general.

To look at the example of media queries and Jon Hicks in particular, it is easy to say “oh, I’ve used media queries a long time ago” (I’ve done that here on this blog ) or “this could have been done using floats”. The point is doing so doesn’t make this less inspiring to people. It doesn’t make it less of a good idea.

I think media queries are a great step forward. Not a solution but an innovation. And one that makes sense as well. It would be narrow minded to ignore the bigger picture of how the web is changing to be at home on a much wider scale of devices. And if you absolutely have to think in negatives in order to to something positive, here’s a problem:

Websites as we build them now don’t work well on devices that are not a desktop or laptop computer.

[update:] I got Mr. HIcks’ first name wrong in my post. I just corrected the mistake. Apologies to Jon Hicks, mistakes like these shouldn’t happen.


What's the benefit of using the Google Font API?

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.


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.


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.


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.


Google IO: bringing webfonts to your site

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


HTML5 session from Google IO showcasing the Google Font API

The video from the “Developing With HTML5” session at Google IO is finally online. Check out t the CSS3 demo at 27:30 to see the Font API in action.

← Previous  1 2 3 4 … 10 Next →