Browsers can do terrible things to type. If text is styled as bold or italic and the typeface family does not include a bold or italic font, browsers will compensate by trying to create bold and italic styles themselves. The results are an awkward mimicry of real type design. In this article you’ll find ways to avoid putting the browser in this bind.
You can’t fault the browser for compensating. The text is supposed to be bold or italic, and if there’s no data available the browser has to do something. So bold appears as a smeared version of regular glyphs, and italic appears as regular glyphs pushed over into a slant. What your users see can be better or worse depending on their browser and the fonts you start with. Some browsers, like Firefox, smear their bolds more, making a mess of display type. Other browsers, such as Chrome, smear their bolds very little, so that the distinction between bold and normal can be lost. None of these faux faces come close to what you can get from a real font.
These faux face styles aren’t much of an issue with web-safe fonts, as most of these fonts include bold and italic styles. But more and more websites with faux-bold are popping up lately, sometimes from designers who should and do know better. In each case, the culprit is web font misuse. Either the web font itself has no bold or italic face, or the @font-face rules are set up incorrectly. These problems can be fixed. Don’t let faux-bold happen on your site.
Headings and single-face display fonts#section2
Consider the case of using a snazzy web font for headings. Perhaps Diplomata at Google Web Fonts catches your eye. Following these instructions, you can set up your h1 elements to use it:
<link href='http://fonts.googleapis.com/css?family=Diplomata'
rel='stylesheet' type='text/css'> <style>
h1 {
font-family: 'Diplomata', serif;
}
</style> Yikes!
With this result in Firefox:
Fig. 1: Faux-bold Diplomata
Diplomata only comes in one face, so the @font-face rule you get is set up as font-weight: normal. Since headings usually have font-weight: bold applied to them, the browser smears the glyphs in an attempt to make its own bold. The font preview you saw had some elegant stripes in the letters’ main strokes and is already a fairly bold weight. The faux-bold the browser creates obliterates these details.
You can fix this for Diplomata by adding font-weight: normal to your h1 styling. But this isn’t a good solution when your web font isn’t available and you have to fall back through your font stack. A better solution is to add an additional @font-face rule for your single-face web fonts to indicate that their normal weights can also be used for bold. Then you get the actual font for your headings and a bold fallback font when fallback happens.
If you follow the googleapi link for Diplomata in Internet Explorer, you can see the cross-browser @font-face rule Google provides. You can take that @font-face rule and add a copy to your CSS, changing the font-weight property to bold.
(Line wraps marked » —Ed.)
<link href='http://fonts.googleapis.com/css?family=Diplomata'
rel='stylesheet' type='text/css'> <style>
@font-face {
font-family: 'Diplomata';
font-style: normal;
font-weight: bold;
src: url('http://themes.googleusercontent.com/static/fonts/diplomata/v1/8UgOK_RUxkBbV-q561I6kPY6323mHUZFJMgTvxaG2iE.eot');
src: local('Diplomata'), local('Diplomata-Regular'),
url('http://themes.googleusercontent.com/static/fonts/diplomata/v1/8UgOK_RUxkBbV-q561I6kPY6323mHUZFJMgTvxaG2iE.eot') format('embedded-opentype'), url('http://themes.googleusercontent.com/static/fonts/diplomata/v1/8UgOK_RUxkBbV-q561I6kD8E0i7KZn-EPnyo3HZu7kw.woff')
format('woff');
}
h1 {
font-family: 'Diplomata', serif;
}
</style> Yikes!
This preserves the design of the font you chose:
Fig. 2: Diplomata without faux bolding
Since Diplomata is fairly bold to begin with, it works as a heading with the normal face. If some other font in the stack gets used instead, the heading will still use a bold face. This duplicating @font-face rules trick can work with other web font services. In this example I’ve duplicated the rule that Google uses, but if you’re constructing your own rules you may want to check out @font-face rule advice from FontSpring, Font Squirrel, or Paul Irish. If your site uses a single-face display font, you can avoid faux faces by including extra @font-face rules.
Note that the CSS3-Fonts specification defines a font-synthesis property that could control whether faux bold or faux italic should happen for a single @font-face rule, but at the moment there are no implementations of this property. Duplicate @font-face rules are the only way to control this behavior in current browsers.
Don’t be tricked into losing bold and italic#section3
The problem of missing bold and italic faces is not limited to single-face web fonts. Many of the web font services let you accidentally omit font faces. Some seem set up to encourage faux faces, either making all of their @font-face rules normal weight and style, or defaulting to include only a single face.
Take Lora from Google Web Fonts as an example. If you follow the defaults, it only gives you one face of the font, which results in this display in Chrome for <strong> and <cite> body text:
Fig. 3: Faux bold and italic Lora
This is not nearly as bad as the Yikes! heading above, but you can see that the bold isn’t really that strong, and the italic looks nothing like the curvy glyphs on Lora’s sample page. Your text may include bold or italic styling implicitly or explicitly, and if you are missing those font faces the browser starts making things up. What you really want looks like this:
Fig. 4: Lora with actual bold and italic faces
The Google Font UI actually warns the user not to include too many styles. Here are the defaults for Lora, where the meter is barely in the yellow, so things look good.
Fig. 5: Web font UI defaulting to missing faces
If you happen to notice that what you’re getting does not match the sample page and decide you’d like to use the other styles, the meter runs straight into the red.
Fig. 6: Web font UI with scary red gauge
If you’re not sure whether you need those extra styles, the meter may fool you into thinking you’re doing something wrong by including them! This encourages dependence on smearing and slanting instead of the real styles this font has available.
I don’t mean to pick on just Google Web Fonts. At least with that service, if you opt in on the bold and italic styles it sets up your @font-face rules correctly. Some other web font services set up a separate @font-face rule for each font in a typeface family, each set to font-weight: normal. This can cause all of the single-face problems to surface even when bold and italic faces are available.
So when you use web font services, take the extra step to verify in a variety of browsers that what you’re getting is what you intended. Make sure your @font-face rules match the weight and styles of the fonts, and that you have a @font-face rule for every style your content uses. Do not assume that the web font service is giving you everything you need. If you’re taking the time to choose a beautiful web font for your site, make sure that you’re actually using the web font and only the web font to display your type.
I love that typography on the web is finally being taken seriously – and this article addresses an issue that has been bugging me quite a bit as of late. Thank you for writing such a well worded, articulate explanation of it for the masses. Hopefully this will bring it into enough of a spotlight that many devs will start to use the process outlined.
Thank you for the well chosen fonts demonstrating the issue discussed.
I am a bit confused about the replacement of the font-weight property in the @font-face rule for Diplomata.
If I state that I want to use font-weight: bold; with a font-style: normal; how does this indicate that the normal font-style is to be considered bold to the browser?
Does the non-existence of a bold style for Diplomata trigger this behaviour?
Compare this with Lora, which provides normal and italic font styles in two weights, so using either style with a bold font-weight would tell the browser which of the four available styles to use.
Thank you again for your article.
Regards
Lesley
Lesley,
The non-existence of a bold style for Diplomata results in a faux bold if you apply the “Diplomata” font-family with a bold font-weight.
The duplicate font face rule with font-weight:bold tells the browser to use the same font file (specified with the src declaration) for both normal and bold font-weight when you apply the “Diplomata” font-family.
Is that helpful?
Thanks,
Alan
I wrote a similar post in 2010: http://spaceninja.com/2010/11/font-face-faux-styles/
I’m always surprised that more people don’t know about this, so I’m thrilled to see it get written up here on ALA.
Spaceninja,
Your post is spot-on. You go into much more detail than I did on how to fix the inadequate @font-face rules you can get from some web font services. I highly recommend everyone who liked my article to go read Spaceninja’s as well.
I’ve been using the javascript implementation for Google fonts lately and I’ve found that they conveniently let us know when the web fonts are loaded. As soon as your Google fonts are active in the page the html element gets the _.wf-active_ class. So in the style sheet I can prepend the font-face styles and include rules about weight and italics with confidence that they’ll only apply when the web font is loaded.
.wf-active h1 {
font-family: ‘Diplomata’, serif;
font-weight: normal;
}
Just another way of getting at it. This approach also has the advantage of giving you a bit of control over FOUT(Flash Of Unstyled Text) (Here’s more information “from Paul Irish”:http://paulirish.com/2009/fighting-the-font-face-fout/ )
Never thought the font of your content can affect your loading time and ultimately the appearance of your website. Great to know some subtle technicalities of content and it’s impact on performance of your website.
I suspect many folks looking for guidance on one of the subtler aspects of implementing web fonts will come away from this article confused.
I did, most certainly.
• Firstly: is the title “Say No To Faux Bolding” an admonition; is it a piece of advice? Do you mean to say Faux Bolding should always be avoided?
If so, I disagree. Sometimes valuable bandwidth can be saved by leaving the bolding to the browser with no ill effect at all.
The following brief paper about RasterBRIDGE® Web Fonts – which uses a font named Auxesis – takes advantage of faux bolding for headings:
http://readableweb.com/rb/rbinfo/rbexplained.htm
I could easily have provided a bold version of the font for the headings but all that would have done is add bloat to the byte count and it wouldn’t have added one whit to the substance of what was being communicated.
So question number one is: are you against letting the browser handle the bolding and italicizing in all instances?
• My second problem is that I don’t think it’s clear that adding a second @font-face rule setting the font-weight property to bold means that the browser will not apply bolding, period.
In other words, bold is killed off in this way, right? – wherever the styling calls for “normal” OR “bold” for that font family, the same weight of font will appear, correct?
• Thirdly – and I’ll do a quick test tomorrow to confirm – because IE8(and less) uses data inside the font to determine whether “font-weight:bold” within the @font-faced rule is valid for the font, the advice given here is, I feel, uncomfortably incomplete. At least a red flag seems in order.
(See the documentation accompanying the free TTF-to-EOT converter EOTFAST, for details about how to set up a font family for normal, bold, italic, and bold italic in IE6, 7, and 8.
http://eotfast.com/
)
Richard Fink
Font Director, Kernest/Konstellations
http://kernest.com
On your first point, my answer is yes. My advice is to always avoid faux bolding when possible. When I load your paper in Mac Firefox, I find the headings and particularly the title distracting. The registered trademark glyph looks more like an icon trying to say “No capital P allowed.”
I’m definitely not in favor of using faux bold and italic as a way of saving bandwidth. If bandwidth is a concern then I think it’s more appropriate to use a web safe font and avoid downloading the web font entirely.
On your second point you are correct. The same weight of font will be used for both normal and bold. So my duplicate font face trick is really only appropriate for web fonts used in headings, where you want to preserve bolding behavior in fallback fonts. The other option in comment 6 might be a good alternative for google fonts, I have not tested it out.
On your third point, you are probably correct that the duplicate font face will not work with IE8. If your test confirms this please let us know.
At my company, our developer does an amazing job making sure our websites fonts are compatible across all browsers. But as a designer, I do think it’s important for me to get involved in that process since it effects the final design and functionality. I will definitely take web-fonts and usage into account on my next design, as I should be integrating this into my process! Thanks for the great detail and insight on this topic!
I’m allways happy reading about custom fonts, the web is full of the old Times new and Arial.
“Offlajn”:http://offlajn.com
Never thought about this until you brought it up – thanks! I’ve been digging more heavily into typography recently and this article came in at a great time.
ESPON® Printer Support just a free call away at 888-817-3484 Toll Free Number. PCASTA, have many noted expert to solve your Epson® printers issues, Epson® Printer Problem, Epson issue, Troubleshooting, error Support. We are able to solve almost all types of Epson® Printers’ errors, Epson® Printer Problems Support.
“EPSON Printer Supporto”:http://www.pcasta.com/support-for-epson-printer/
Interesting article. I’m still a little new to using web fonts. When you make the @font-face rule, how are you getting the font URLs listed in the rule?
src: url(‘http://themes.googleusercontent.com/static/fonts/ »
diplomata/v1/8UgOK_RUxkBbV-q561I6kPY6323mHUZFJMgTvxaG2iE.eot’);
src: local(‘Diplomata’), local(‘Diplomata-Regular’),
url(‘http://themes.googleusercontent.com/static/fonts/diplomata/v1/ »
8UgOK_RUxkBbV-q561I6kPY6323mHUZFJMgTvxaG2iE.eot’) format(’embedded »
-opentype’), url(‘http://themes.googleusercontent.com/static/ »
fonts/diplomata/v1/8UgOK_RUxkBbV-q561I6kD8E0i7KZn-EPnyo3HZu7kw.woff’)
format(‘woff’);
If I’m using another Google font, how would I get that information? I don’t see it anywhere in the Google Web Fonts site.
Thank you for this greate article!And I want to know the result of Richard Fink’s test.
SinisterKid,
For Google fonts, the rule I used came from following the link href in the “Add this code to your website” part of their UI. If you follow the link in IE, you get the most cross-browser @font-face rule that service provides.
Thank you! Got it. Thanks for the help and the article, very educational.
Great suggestion, but the overall result of these new best practices is the increased workload for the type foundries and designers, who must now create additional styles (bold, italic, etc) for their digital fonts. Most of the trendy new design fonts only have a single variant to begin with.
I wasn’t aware of this as a problem with web design fonts. Now i know that i need to be more selective in the family fonts i chose, and whether or not i choose to bold them.
Makes perfect sense though; and your article outlines very clearly all the relevant key points.
Great article!
It is so true that HTML editors, unlike more publish oriented software, often ignores the type and font designations. It was common, and still is, to have multiple font choices for the browser to pick from. Since until recently, browsers and/or the OS stored fonts, and the web page authors could only guess on what fonts would be served by the various browsers, pretending to have any control was nearly useless.
Finally, with HTML5/CSS3 compliant browsers, we finally can truly start to deal with typefaces, fonts, if not kerning, etc. And since the HTML editors within a CMS(Content Management System) often cannot handle the uses of bold and italic and standard HTML style elements like H1…H5, or keep them from overlapping, this leaves it difficult to compensate.
Better web site publishing that integrates tightly controlled styles and CSS with the system to edit content is needed. And, since some browsers cannot handle this, old browsers will still cause problems, it is important to still use “serif” etc.
Also, since semantic understanding is the reason for styles, use of bold, cite, H1, italics, strong, and the rest, must continue to be present, so do not let style settings undo understanding.
By the way, this problem of worrying about fonts on web pages is a beautiful problem to have (pun intended). How to present content in as clear a way possible is the whole point. Now if we can better address printing web pages …
Daniel Bennett
Well! thanks for informative article. I am working for Minneapolis Web Design firm now. I could easily have provided a bold version of the font for the headings but all that would have done is add bloat to the byte count and it wouldn’t have added one whit to the substance of what was being communicated. So question number one is: are you against letting the browser handle the bolding and italicizing in all instances?
Great article. Just one thing to add; substituting faces can work nicely for fonts with missing variants: Avoid faux bold with Web Fonts