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.
Copy & paste the code below to embed this comment.
lesleyb
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.
Copy & paste the code below to embed this comment.
Alan Stearns
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.
Copy & paste the code below to embed this comment.
Alan Stearns
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.
Just another way of getting at it. This approach also has the advantage of giving you a bit of control over FOUT (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.
Copy & paste the code below to embed this comment.
Richard Fink
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 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
Copy & paste the code below to embed this comment.
Alan Stearns
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!
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.
Copy & paste the code below to embed this comment.
backlinkbuilder
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.
Copy & paste the code below to embed this comment.
SinisterKid
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?
Copy & paste the code below to embed this comment.
Alan Stearns
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.
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.
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 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 …
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?
22 Reader Comments
Back to the Articledesigncouch
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.
lesleyb
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
Alan Stearns
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
spaceninja
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.
Alan Stearns
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.
natewalton
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 (Here’s more information “from Paul Irish”:http://paulirish.com/2009/fighting-the-font-face-fout/ )
jhonadam@serpholic
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.
Richard Fink
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 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
Alan Stearns
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.
BopDesign
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!
offlajn
I’m allways happy reading about custom fonts, the web is full of the old Times new and Arial.
“Offlajn”:http://offlajn.com
ajtreat
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.
backlinkbuilder
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/
SinisterKid
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.
crocodile
Thank you for this greate article!And I want to know the result of Richard Fink’s test.
Alan Stearns
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.
SinisterKid
Thank you! Got it. Thanks for the help and the article, very educational.
Paul Geronca
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.
justincaron
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!
citizencontact
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 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
Katie Gray
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?
Matt Montag
Great article. Just one thing to add; substituting faces can work nicely for fonts with missing variants: Avoid faux bold with Web Fonts