10

We are using some web fonts on our site, e.g.

<link href="http://fonts.googleapis.com/css?family=Anton" 
    rel="stylesheet" type="text/css">

Due to a bug in IE8 that I have no desire to workaround in other ways, I'd like to recommend to our site authors that they not provide a fallback font when specifying web fonts. For example, instead of:

font-family: 'Anton', "Arial Black", sans-serif;

..do...

font-family: 'Anton';

Is there a real-world scenario where this could cause problems, i.e. why would I need to provide a fallback for a font that I am providing?

Community
  • 1
  • 1
Steve Campbell
  • 3,385
  • 1
  • 31
  • 43
  • 5
    What if there's a firewall that's blocking the user's access to the webfont? Or what if the webfont host is down? What if Google removes the font or renames it? – Roddy of the Frozen Peas Aug 28 '12 at 16:53
  • The same could be said of the jQuery library that we use from Google's CDN. We don't provide a fallback for that, and it is much more critical to our pages than web fonts. – Steve Campbell Aug 28 '12 at 19:19
  • The thing about JQuery is that it's so ubiquitous on the web that it's in most peoples' browser caches anyway. The same cannot be said for custom webfonts. – Roddy of the Frozen Peas Aug 28 '12 at 19:21
  • Visitors browsing with NoScript will also not see your Google font by default. Worth bearing in mind if you are targeting a techy audience. – Matthew Sharpe Aug 30 '12 at 14:04

11 Answers11

5

Google fonts use @font-face tag. Fallback font is suppose to keep your design/layout looking consistent when @font-face is not supported or available.

Reference: http://webdesignerwall.com/tutorials/css3-font-face-design-guide

user1512616
  • 509
  • 3
  • 6
  • Thanks, the linked article helps my understanding, although it leaves me with the same original unanswered question. You can see a similar question/statement in the comments on that page - http://webdesignerwall.com/tutorials/css3-font-face-design-guide#comment-95050 - there does not seem to be any advantage to providing a fallback font, as there are not any real-world scenarios where it fails. – Steve Campbell Aug 21 '12 at 17:25
  • 1
    @SteveCampbell although the chance is very small, there *is* always the possibility that Google can not serve the font (in the case that you include it the way you describe in your example, instead of a local font). According to Murphy's law, this will happen sometimes. I for one would not take the risk and make sure I got a fallback, to at least have little control over what is being shown (For instance serif, non-serif etc) – Dirk McQuickly Aug 21 '12 at 19:38
5

To not use a fallback would mean that you have perfect faith in the following:

  • that your site will always be loaded with a good internet connection
  • the external font asset will always be perfectly available at the location you request it at
  • that if your font doesn't load, the affected text in the site will look absolutely fine, without the font

If you disagree with any of those, then yes, you should have a fallback font, which is designed to be a fallback, in case your original choice is unvailable.

Kristian
  • 21,204
  • 19
  • 101
  • 176
4

If the Google 'font server' is down, unreachable or otherwise, the browser would fall back to it's default font, I think. So in that case, it might be handy to have a fallback font defined yourself.

Dirk McQuickly
  • 2,099
  • 1
  • 17
  • 19
3

I doubt you would have a problem with Google being unreachable. However some browsers do use the fallback font until the downloaded font is available.

From Google: https://developers.google.com/webfonts/faq

How is text displayed while the browser is still loading the font file?

Browser behavior varies depending on the type of browser. Some will only display the text after the font file is loaded, others will use the fallback font from the font stack and then refresh the page when the font is available. The latter behavior is generally referred to as the "flash of unstyled text." For browser details, see the Technical Considerations page.

For greater control over how browsers behave while the font is still loading, use the WebFont Loader.

Jeremy A. West
  • 2,162
  • 4
  • 27
  • 40
  • Thanks for this answer. Any idea what these browsers do when there is no fallback font? (This might actually be an *advantage* to not specifying a fallback font, as it makes those problematic browsers behave more consistently). – Steve Campbell Aug 29 '12 at 15:27
  • 2
    @SteveCampbell if there is no fallback font at all, it will use the browser's default font which maybe different for everyone as the user will set this up in their browser option. – user1512616 Aug 29 '12 at 16:34
  • If you read here about font stacks in css http://www.maxdesign.com.au/articles/font-stacks/ it is web designer's practice to use fallback fonts to make their design looking consistent. What Jeremy described is call the font-face FOUT. More info: http://paulirish.com/2009/fighting-the-font-face-fout/ – user1512616 Aug 29 '12 at 16:48
2

...depends on your Application of Fonts:

Design relevant

  • If it's a Design-Resource that adds some extra sugar on top of your App it's cheaper and maybe better to leave the Text using that font instead of showing some wrong styled Elements. e.g. big special letter or sign in the Background (like: " ? ! #)
  • If its crucial for very design centric pages - a better Fallback would be some static Graphics or one rendered from the Font e.g. via (Typeface / sIFR / Cufon)

Function relevant

  • using your special font for default interaction items (submit / button / links etc.)
  • using Fonts to deliver unique Icons (Iconsets via Raphael) for e.g. navigation elements its absolut crucial to handle the fallback since it will affect known and unknown portions of your users. Now you know about IE8 issues and don't want to take the effort to handle them but whats with all the browsers & systems in the wild - if you know your userbase systems (intranet / company environment) or can't handle to scale now to greater support (time to market / development costs) its ok to leave it for the moment

Content Styling

  • That's the perfect fallback scenario, no extra cost and customers can still read your articles / Headlines etc. In this case it's just a bad manner to leave the possibility to fallback away.
  • Print Support might fail if no standard Font is given (printing issue example)
  • Operating System / Assistence System that raise Contrast and readability or remove Fonts for the sake of getting the Content readable use own or default fonts

I'm surely missed some application - for better help please specify the type of usage, in best case with some example. But in all cases - you can not assume that a external resource is loading - so if you want the user to deal with your App allow him to do so independent from network reliability, speed or system limitations.

regards.

Community
  • 1
  • 1
MarioW
  • 86
  • 5
  • I think the most common scenario on our site is what you call "design relevant". Thanks for the link to http://stackoverflow.com/questions/692990/sifr-vs-cufon-vs-typeface-js, i was not aware of that option. – Steve Campbell Aug 29 '12 at 15:20
2

Its always a good idea to at least provide ONE fallback: serif or sans-serif. This font will display in case the @font-face request fails, or takes too long to load.

Additionally, you can achieve fine-grained control over how your website loads by using the google font loader.

https://developers.google.com/webfonts/docs/webfont_loader

Kostia
  • 6,284
  • 1
  • 18
  • 15
1

Trust nothing on the web, except Murphy's Law.

I always indicate fallbacks (<offtopic>and on the other side I'm searching for a Firefox extension that would deactivate font-face on a per site basis, more like QuickJava than Stylish or Greasemonkey. That and no more position: fixed on other pages because of crappy websites. Just expect users to start to use that when they'll be fed up with poor choices and abuse from some designers. Not all, some.</offtopic>) because it costs me 10 to 16 bytes in a gzipped and minified stylesheet and causes no other problem in my case.

If it does cause problems to you then weigh pros and cons and decide.

You will have a fallback: it's the default font of the default family (serif); Times or Times New Roman most of the time (except on some or most Linux I believe).

If your site displays well with serif on OS X, Windows and Ubuntu then you solved one of your problems.
If you're:

  • expecting pixel perfect rendering even with such different renderings than Firefox, IE and Chrome on XP, W7, OS X and Ubuntu with "Cleartype" or not activated by users,
  • using height instead of min-height
  • and so on

well you'll maybe learn the hard way that you shouldn't expect much from the systems used by your visitors.

FelipeAls
  • 21,711
  • 8
  • 54
  • 74
1

You need to provide a fallback font for non-JS browsers. Admittedly on the desktop this is an uncommon problem, and only likely to be relevant if you sell goods. However, for responsive designs that need to support a wide range of devices, then you need to have a non-JS fallback for them.

frak
  • 858
  • 1
  • 10
  • 30
0

If you visit that stylesheet link you get...

@font-face {
   font-family: 'Anton';
   font-style: normal;
   font-weight: 400;
   src: local('Anton'), 
   url(http://themes.googleusercontent.com/static/fonts/anton/v3/tilmJBBU81h1G7ZsdY3Hmw.woff) format('woff');
}

Where it says local('Acton') it looks for the user to have a local copy of Acton, so you could perhaps write something like local('Acton'), url('http://themes.google...), local('Arial'); instead and then linking to your own edited style instead of the one through google's api... but I'm not sure if that will A) work correctly, or B) violate some terms of service (though I don't really see why it should).

0

The 'woff' format supplied by Google doesn't function across all browsers and devices.

Here's a small list of the formats with browser supports:

  • .TTF: Firefox 3.5+ , Opera 10+, Safari 3.1+, Chrome 4.0.249.4+
  • .EOT: Internet Explorer 4+
  • .WOFF: Firefox 3.6+, Internet Explorer 9+, Chrome 5+
  • .SVG: iPad and iPhone

The systems that can't render the 'woff' format will most likely use Times New Roman or whatever the system's default font is. If you're fine with that then there's nothing wrong with Google's service.

If not then I'd suggest using the Font Squirrel @font-face Generator (or a similar converter) to create all the necessary formats of your font and use @font-face to load the formats directly from your server.

Eg.

@font-face {
font-family: 'EnigmaticRegular';
src: url('../fonts/Enigma__2-webfont.eot');
src: url('../fonts/Enigma__2-webfont.eot?#iefix') format('embedded-opentype'),
     url('../fonts/Enigma__2-webfont.woff') format('woff'),
     url('../fonts/Enigma__2-webfont.ttf') format('truetype'),
     url('../fonts/Enigma__2-webfont.svg#EnigmaticRegular') format('svg');
font-weight: normal;
font-style: normal; 
}
0

Yes you should still provide fall back fonts. Having them gives you greater control while not having them leaves you at the mercy of the client. http://cssfontstack.com/ is a good resource to find the appropriate fonts.

Malk
  • 11,855
  • 4
  • 33
  • 32