@font-face uses

Hello all,

I am just curious as to your use (if any) of @font-face.

If you use it for more then just headings, do you find it takes a page longer to load, for instance.


1 & 3) Use image replacement techniques like Gilder-levin. End of worries about SEO or accessibility since images off you should still have text, even if it’s not styled.

  1. If you need more than 10k for EVERY image replacement heading on your page you’re probably screwing up the encoding.

  2. Though yes, having to go back and create a new image every time is a royal pain in the ass.

Really it’s only that last one that prevents me from doing it unless the client REALLY demanded it… but your first three claims? Pure nonsense… typical of what one often hears when people are still using IMG tags for presentational images (which have no business in the markup in the first place)

SVG yes - but Javascript? :confused: Where? FontSquirrel packages don’t include any Javascript, just some really tricked-out CSS…

They use SVG and JavaScript to render the font’s appearance, so it does technically work but it’s not the same as having the physical fonts. :slight_smile:

FontSquirrel claims support on the iPhone and iPad. I haven’t tried it myself.

Not when I’m designing

I agree, I think unless requested from now on it’ll only be straight up text until a real solution presents itself.

Not when I’m designing :slight_smile:

If you slice images for headings:

  1. SEO goes down the sink - headings are important.
  2. Bandwidth efficiency follows SEO down the sink.
  3. Accessibility follows bandwidth on the same one-way trip.
  4. You have to regenerate the graphics every time you change the text.

So, if I don’t want to use @font-face, I just use an ordinary font.

I use font-face for heading only

My post referred to the antiquated methods of yesteryear, i.e.

<h1><img src="heading.png" alt="my heading text"></h1>

This primative implementation does of course have a noticeable impact on both accessibility and SEO.

It’s good to know about the new ways of implementing image-replacement. Gilder-Levin is interesting but looks like a lot of trouble.

  1. If you need more than 10k for EVERY image replacement heading on your page you’re probably screwing up the encoding.

I assume you mean 10K each (?), which I think is a bit high, so let’s go with just 5K each. I believe we can fairly estimate that an average page has at least 4 to 8 headings, including nav elements etc. Multiply one figure by the other and you have 20-40K in extra bandwidth (per page, in many cases, as unique headings aren’t cached) - plus all those additional HTTP requests.

Admittedly, it is perhaps too extreme to characterize this hit as bandwidth “going down the sink” - I hadn’t actually crunched the numbers when I posted. :slight_smile:

You don’t consider @Font-face a real solution? Rather strange because it’s part of the W3C specifications

Not necessarily, it’s just people mention issues & it’s not used extensively yet. I’m going to experiment with it a bit more in the upcoming weeks.

You don’t consider @Font-face a real solution? Rather strange because it’s part of the W3C specifications, the foundries are loosening their restrictions, the browser makers are standardising the container format and it’s the most accessible solution for alternative typography that exists. The real solution is here, it just needs a bit of time to mature. My only current concern is the lack of mobile device support for font-face, but if used in a stack, that’s a non-issue. :slight_smile:

So slicing images is still King eh?

Thanks for the replies. I played around with fontsquirrel as well, and was pleased with the results … but still undecided on the extent I might use this.

iPhone fa… uhm, users… and remember on the Mac you have people who don’t know enough about computers to even install their own software (buddy of mine’s father comes to mind – and that’s an accomplishment on a Mac) since the Quackintosh is for people who know nothing about computers (which is why they’re the only ones dumb enough to buy them in the first place)… as such don’t expect them to change from the default browser (see all the IE users for the same reason)

I can agree with that part at least.

FontSquirrel is the best approach for people nervous about trying it, and for saving time when trying to do it. The problems that remain make it not even worth trying to do for me… but it really makes me laugh at the people who thought “google font api” was some new thing. If it wasn’t for the horrible rendering issues in Safari (like it ignoring top padding and line-height/vertical align) I’d be giving it a serious look for a handful of projects… like where I want a GOOD monospace font.

One of the biggest problems with @font-face is licencing of fonts. For the most part decent fonts are not allowed to be distributed that way which means that even once cross browser issues with using the command are resolved it will still not be possible to use it legally to use most of the better fonts. You would still only be able to legally use the font on your own computer and in derivative works such as images of the text and would not be able to distribute the font itself. If you did manage to use it for quality fonts that are not allowed to be used that way you could easily find your site shut down for breaching the copyright on the font you are using.

Interesting, you’re right. I assumed that they used JavaScript to perform a switch toward VML so that Windows Mobile devices could use the alternative.

Perhaps one day we’ll have something that’s totally cross-platform compatible without involving many standards and specifications! :slight_smile:

BTW, a good point about Google’s web font kits has been made before and bears repeating: Since the Google fonts (whch work on much the same principle as FontSquirrel, I believe) are centrally hosted with Google, they will get cached by many people’s browsers as they become more popular. This might help performance significantly compared to hosting our own. Of course, you’re then limited to about 15 fonts.

Great news about the foundaries loosening up their licensing! :slight_smile:

Yes, it will inherently give the page a performance hit because it’s yet another HTTP request (or more) for the file to be accessed, another thing to download (and fonts can get pretty big in terms of file size if they have a full Unicode set) and therefore it’s another resource for the users browser to deal with and render. There will be an impact, but it will be less of one than using something like sIFR which is Flash + Font + Resource + Render * number of inclusions. :slight_smile:

I don’t agree with that, just because people can abuse it doesn’t mean that everyone will. I certainly have been considering using custom typefaces to increase the user-experience but I do agree that most average web designers will be moronic enough to reincarnate the Comic Sans for everything ideology with some forsaken illegible symbolic font thinking it’s smart and clever. That being said, I still say for all the abusers there really is a benefit in being able to use a better set of typefaces.

That won’t be an issue for much longer. Most of the foundries have suddenly realised that everyone wants to use their paid for fonts on the web and have been beginning to convert their libraries and licenses to accommodate such requirements. I know for a fact that Adobe, Linotype, Bitstream, Monotype, DTL, Ascender, FontFont, CommercialType and others are getting on the web bandwagon. So the legality will become less of an issue as the standards solidify.

Amen to that, those methods are hacky and really drag a sites performance.

I didn’t know people still used Safari, that browser has managed to become more bloated, uglier, less frequently updated and a poorer performer than Internet Explorer… and that deserves some sort of award. Anyone in their sane mind wanting to use a Webkit renderer would dump Safari in place of Chrome. :slight_smile:

I use @font-face kits provided by FontSquirrel, which I learned about here on the forums and which Russ Weakley recommended when asked about it during a CSS Live session. FontSquirrel uses multiple formats and a rather clever CSS technique to achieve @font-face support on all major browsers. As felgall mentioned, it’s very important to make sure the fonts you use in this way are truly open-source. Of course there’s a performance hit; the files are not small. However, the FS generator allows you to narrow down the included glyphs for minimal size, and I think the increased load is worthwhile in some cases.

At any rate, it beats using SIFR, typface.js, or cufon.

Hope this helps.