Overview of browser @font-face support: http://webfonts.info/wiki/index.php?title=%40font-face_browser_support

IE does support it since version 4.0. Chrome could support it (since it's built on the Webkit framework), but it's currently disabled. The fonts are even downloaded ...

Hmmm, i'm surprised by IE! Any clues why it's blocked in Chrome?

More: But IE only supports EOT, can that really be considered @font-face support?

can that really be considered @font-face support?

People often mix up @font-face, EOT and "raw fonts". @font-face is the general technology; EOT, TTF, OTF, SVG and so on are possible formats which can work with @font-face depending on the browser support. (Similar to GIF/JPG/PNG and the IMG tag)

yes, i know that @font-face is just a css rule. the confusing things is that each of the browsers only supports certain font formats with this rule. to me it almost makes no sense to speak of @font-face support in general then. If speaking about @font-face support it would make more sense to differentiate between @font-face embedding for 'raw' or 'naked' fonts and @font-face embedding for encrypted font formats, ie EOT.

would make more sense to differentiate between @font-face embedding for ’raw’ or ’naked’ fonts and @font-face embedding for encrypted font formats, ie EOT.

The line is hard to draw. You could also built an EOT font without URL-binding and compression and obfuscate a "raw" font, so it's not really raw any more ...
And it's getting more complicated now that new formats are being proposed. Some more information:
http://opentype.info/blog/2009/07/29/why-webfont-services-are-the-future...
http://ilovetypography.com/2009/07/20/web-fonts-—-where-are-we/
http://new.typographica.org/2009/on-typography/audio-from-the-web-fonts-...

Paul: the confusing things is that each of the browsers only supports certain font formats with this rule. to me it almost makes no sense to speak of @font-face support in general then.

Certainly talk of @font-face support needs to carry this caveat, that different font formats are required to display @font-face linked fonts in different browsers. But in terms of recognising @font-face in CSS and doing something with that information, one can say that all these browsers support it.

Services like Typotheque's, Typekit and Kernest serve different file formats to different browsers as appropriate, while trying to provide some measure of server-side or in-font obfuscation to naked font data to make it uninstallable on desktop systems. So they can claim to support ‘95% of all browsers in use’ even though those browsers support @font-face in different ways.

From a type foundry perspective, considering whether to sign up for any of these services, a key question is whether the methods of obfuscation of naked font data provided are sufficient. You probably also want to make sure that your web font license and your contract agreement with these service providers specifies that such methods are a requirement, i.e. that naked font data should not be served without such measures.

I think it would make more sense for everyone to stop using the terms embedding and @font-face when discussing web fonts and be specific about what font formats browsers support. Many web designers aren’t even writing code, they have production staff for that, so talking about a specific CSS rule isn’t very helpful. I do think those designers can handle an explanation of what font formats are supported, which might lead to designers leaning on Microsoft to support raw linking and lean on all browser makers and the W3C to get a good web font standard defined and implemented.

James, your first sentence more clearly explains my own thinking. Thanks for piping up.

@james puckett
"Many web designers aren’t even writing code, they have production staff for that, so talking about a specific CSS rule isn’t very helpful."

Huh? I'm not getting this. What kind of web designer doesn't have some working knowledge of CSS?
What do you mean by web designer, then?
I hardly think of CSS as "writing code".
Straighten me out on this.

"I’m not getting this. What kind of web designer doesn’t have some working knowledge of CSS?"

The bad ones. ;)

It’s not uncommon for graphic designers to have little or no knowledge knowledge of XHTML/CSS and to handle web design by mocking up sites in Photoshop or InDesign. The design is then passed on to production staff who handle all of the HTML/XHTML/CSS/backend setup.

Well. I am a graphic designer and did a week long course on webdesign when HTML 2.0 was hot, and I am confounded by all this @font-face stuff…
But I am quite sure that after the clouds of warfare have settled things will become a lot clearer.
In other words: most designers will wait out the font wars and get into the game when some semblance of consensus has been achieved.

. . .
Bert Vanderveen BNO

> Any clues why it’s blocked in Chrome?

Because of security concerns, apparently: http://lists.w3.org/Archives/Public/www-font/2009JulSep/0823.html

JP: ...which might lead to designers leaning on Microsoft to support raw linking

So far, the only pressure I've seen from web designers/authors has been on the other browsers to support EOT Lite, because it is the only format that offers a significant measure of backwards compatibility with well over 50% of browsers in current use.

And I think the chances of MS supporting raw linking are now close to nil.

...and lean on all browser makers and the W3C to get a good web font standard defined and implemented.

That we're working on.

Paul, I understand this is indeed confusing, especially since Internet Explorer has supported @font-face for a very long time, but very few people took advantage of this. But in a way, this is not so much different from another basic HTML code: <img src="url" />

Not every browser supports all image formats (e.g. PNG, BMP), the designer has to choose the format that is best for the purposes. Hopefully, we'll soon have one font format that works in all browsers, so we don't have to specify two or more* font formats per single web page.

Peter
http://www.typotheque.com

* It is a fact that right now, we deliver subsetted and obfuscated TTF for some browsers, and the same font wrapped in EOT for other browsers. But because we aim for multilingual support, we realise that even this may not be enough, as Apple requires AAT fonts for correct shaping of some non-Latin scripts. I am just playing with Devanagari fonts, and while on Windows this sample (http://www.typotheque.com/hindi.html) is rendered correctly in all browsers, on Mac the conjuncts are not correctly rendered. The sample is in fact Nepalese, not Hindi.

Does anyone have any inside info on the status of TypeKit? There hasn't been an update for quite a while now. In the meantime, I've had decent luck with the Font Squirrel website. they've organized the their fonts into @font-face kits complete with the proper CSS syntax. Pretty decent selection, too.

Peter,
Thanks for chipping in. The Devanagari sample is quite interesting. For your own information, I am on Win XP and getting Fedra Devanagari in Firefox (3.5.1) and IE (6), but Mangal in Chrome (2.0.172.39) and Safari (4.0.2).

I know that current version of Chrome doesn't support @font-face, but I wonder what's up with Safari 4.0.2? I suppose you see other @font-face pages there? Is it Devanagari issue only? Sorry I have no Win machine at the moment.

Peter
http://www.typotheque.com

Interesting... I just checked again and the correct font is now showing in both Safari and Firefox. Perhaps the browser wasn't properly downloading the font earlier? In any case it seems to be working correctly now.

p

.