{"id":56,"date":"2013-07-02T21:00:37","date_gmt":"2013-07-02T21:00:37","guid":{"rendered":"http:\/\/aurelio.audero.it\/blog\/?p=56"},"modified":"2016-06-20T01:36:12","modified_gmt":"2016-06-20T01:36:12","slug":"how-to-solve-the-problem-of-font-face-inside-media-queries","status":"publish","type":"post","link":"https:\/\/www.audero.it\/blog\/2013\/07\/02\/how-to-solve-the-problem-of-font-face-inside-media-queries\/","title":{"rendered":"How to Solve the Problem of @font-face Inside Media Queries"},"content":{"rendered":"

Mobile connections aren’t as good as the usual desktop ones, therefore the download time of custom fonts can take up to several seconds. A good approach is to use the @font-face<\/code> rule only for certain range of media and screens using @media<\/code> queries. Unfortunately this approach doesn’t work for some browsers: all the versions of Internet Explorer and FireFox 10 and lower. This article discusses a solution for this problem that balances performances and hacks.
\n<\/p>\n

\n MAJOR UPDATE: With certain constraints, a better approach than the one discussed in this article exists. More info here<\/a><\/ins>\n<\/div>\n

What’s the Problem?<\/h2>\n

When I started creating my new website, I wanted to create a strongly mobile optimized design having also in mind the achievement of high performances. One of the thing I really wanted to avoid was the effect, seen on several websites when I access them through my smartphone, of a white block where it’s supposed to be the content. This issue is caused by a custom font, applied to the text, that it isn’t completely loaded as shown in the image below.<\/p>\n

\"A<\/a><\/p>\n

So, what’s the solution? A good approach is to apply a custom font, using the @font-face<\/code> rule, only for certain range of media and screens, using @media<\/code> queries. You might think that the best solution would be to apply the custom font only to those users visiting the website with a fast connection, and you’re absolutely right. Unfortunately there isn’t yet such a system although it has been discussed<\/a> several times on the WHATWG<\/abbr><\/a> mailing list.<\/p>\n

@font-face inside a @media query<\/h2>\n

To better explain the solution, we’ll create two files: index.html<\/code> and style.css<\/code>. The first is the ideal page having the text with the custom font applied while the latter contains the style of the page.<\/p>\n

An hypothetical index.html<\/code> page could be the following:<\/p>\n

\r\n<!DOCTYPE html>\r\n<html>\r\n   <head>\r\n      <link rel="stylesheet" href="style.css" \/>\r\n   <\/head>\r\n   <body>\r\n      <p>\r\n         This is an amazing text because has a custom font.\r\n      <\/p>\r\n   <\/body>\r\n<\/html>\r\n<\/pre>\n
As you can see, it’s very basic since it has only one paragraph and the link to the stylesheet.<\/p>\n
The following, instead, is an hypothetical source for the style.css<\/code> file using a mobile first approach:<\/p>\n
\r\np {\r\n   font-family: Arial,Helvetica,sans-serif;\r\n}\r\n\r\n@media only screen and (min-width: 980px) {\r\n   @font-face {\r\n      font-family: "OctinSports";\r\n      src: url("fonts\/octinsports.eot");\r\n      src: url("fonts\/octinsports.eot?#iefix") format("embedded-opentype"),\r\n      url("fonts\/octinsports.woff") format("woff"),\r\n      url("fonts\/octinsports.ttf") format("truetype"),\r\n      url("fonts\/octinsports.svg#OctinSports") format("svg");\r\n      font-weight: normal;\r\n      font-style: normal;\r\n   }\r\n\r\n   p {\r\n      font-family: "OctinSports";\r\n   }\r\n}\r\n<\/pre>\n
The stylesheet shown, sets for all the paragraphs an Arial font, with several fallbacks. The font stack used is composed of fonts that are really common and highly present in the major operative systems. In fact, based on CssFontStack<\/a>, Arial achieve the 99.84% on Windows and the 98.74% on Mac. In case none of the selected fonts is available, the CSS asks for a generic sans-serif font.<\/p>\n
The second part of style.css<\/code> specifies the media query. With it, we’re targeting all the devices that have a screen and with the screen’s width of at least 980px (you can use a different breakpoint). Inside it, we’ve the @font-face<\/code> rule to download the custom font, using the Fontspring Bulletproof @Font-Face Syntax<\/a>. Then, we’re simply applying the new font to all the paragraphs, overriding the previously set style.<\/p>\n
Browsers Compatibility<\/h3>\n
This solution is really smart because it applies a custom font only for users that have a big screen and should not have problem for a little bandwidth overhead. Unfortunately, this approach is not<\/em> supported by Internet Explorer 10 and lower, and Firefox 10 and lower<\/a>. Although you can think it’s a strange behavior, it actually comes from the CSS2.1 specifications<\/a> that asserts: At-rules inside @media are invalid in CSS2.1.<\/q><\/p>\n
So, while the last version of Internet Explorer still doesn’t support this feature, the company behind FireFox, Mozilla, added the support<\/a> for versions after the 10th. Therefore, the issue is significant only for Internet Explorer. Another point to keep in mind is also that Internet Explorer 8 and lower doesn’t understand @media<\/code> queries, so even if they updated new versions, the problem would remain for older ones.<\/p>\n
How to (Partially) Solve the Problem<\/h2>\n
Is there a way to solve the problem of @font-face<\/code> inside a @media<\/code> query in Internet Explorer? The answer is yes, partially.<\/p>\n
As I said in the introduction, I came across this issue during the development of my website. I wasn’t aware of the compatibility problem of Internet Explorer, so, just like every good developer, the first thing I did to understand what was going on, was to use Google. During my research, I found an article titled Do Not Put @font-face Inside @media Query<\/a> that gave the answer needed on the cause, but not on the solution. Besides, the article also suggested to not have @font-face<\/code> inside @media<\/code> queries. I was really determined to solve the issue, so I searched a little more. Unfortunately, I didn’t succeed, so I decided to create one by myself.<\/p>\n
Solve the Problem for Internet Explorer 9 and Lower<\/h3>\n
Based on what I described so far, the problem is relevant only for Internet Explorer, so we can try to target this specific browser. The first thing that could came to mind is to create a separate CSS file, for example fonts.css<\/code>, containing all the @font-face<\/code> rules, not into a @media<\/code> query, and use a conditional comment<\/strong>. Thus, the source of fonts.css<\/code> should be like this:<\/p>\n
\r\n@font-face {\r\n   font-family: "OctinSports";\r\n   src: url("fonts\/octinsports.eot");\r\n   src: url("fonts\/octinsports.eot?#iefix") format("embedded-opentype"),\r\n   url("fonts\/octinsports.woff") format("woff"),\r\n   url("fonts\/octinsports.ttf") format("truetype"),\r\n   url("fonts\/octinsports.svg#OctinSports") format("svg");\r\n   font-weight: normal;\r\n   font-style: normal;\r\n}\r\n<\/pre>\n
Using this approach, we have the advantage of keeping the weight of the page the same as before, apart for the few bytes for the conditional comment part, for all the browsers but Internet Explorer. For the latter, instead, we’ll add also a little overhead because of the additional stylesheet to download. However, containing only the very few lines about @font-face<\/code> rules, minimizing it, an average file should cause an additional weight of no more than 1-2kb<\/strong>, that in most cases is an acceptable compromise.<\/p>\n
The code that implements the approach, using the minified version, is the following:<\/p>\n
\r\n<!--[if IE]>\r\n   <link rel="stylesheet" href="css\/fonts.min.css">\r\n<![endif]-->\r\n<\/pre>\n
This solution is simple but not definitive because, as you might know, Internet Explorer 10 dropped support for conditional comments<\/a>, so this version will ignore the snippet. In conclusion, our problems aren’t ended yet.<\/p>\n
Solve the Problem for Internet Explorer 10<\/h3>\n
To target IE10 we’ll use a less clean approach, because we need a hack, but that works fine. Specifically, the hack used is based on JavaScript and is discussed in the article IE10 CSS Hacks<\/a>. What this snippet does is to detect IE10 and test if the window’s width is greater than or equal to 980px. If these conditions are true, it adds the same fonts.min.css<\/code> stylesheet to the <head><\/code> element of the page. Remember that since it’s based on JavaScript, if the latter is disabled the hack won’t work.<\/p>\n
\r\n<!--[if !IE]><!-->\r\n   <script>\r\n       if (Function('\/*@cc_on return document.documentMode===10@*\/')() && window.innerWidth >= 980) {\r\n          var link  = document.createElement('link');\r\n          link.rel  = 'stylesheet';\r\n          link.href = 'css\/fonts.min.css';\r\n          document.getElementsByTagName('head')[0].appendChild(link);\r\n       }\r\n   <\/script>\r\n<!--<![endif]-->\r\n<\/pre>\n
How this Solution Deals with a Responsive Web Design Approach?<\/h3>\n
A good question that you can arise is how this solution actually solves the responsive approach of a website. To answer this question, let’s split the discussion into two branches. The first regards mobile users where we don’t<\/em> want the custom font, and the second regards desktop users where we do<\/em> want the font to be applied.<\/p>\n
Mobile Users<\/h4>\n
To start the discussion, let’s have a look at the last statistics (June 2013) about mobile browsers usage<\/a> provided by StatCounter<\/a>. The link gives us the following statistics:<\/p>\n
    \n
  1. Android: 29.06%<\/li>\n
  2. iPhone: 22.77%<\/li>\n
  3. Opera: 16.06%<\/li>\n
  4. UC Browser: 9.89%<\/li>\n
  5. Nokia: 7.38%<\/li>\n
  6. Chrome: 3.23%<\/li>\n
  7. BlackBerry: 3.11%<\/li>\n
  8. NetFront: 2.40%<\/li>\n
  9. iPod Touch: 2.21%<\/li>\n
  10. Others: 3.9%<\/li>\n<\/ol>\n
    An important important point to get from these statistics is that none of them is Internet Explorer, and that its usage has been counted in the voice “Others”. However, thanks to Craig Buckler<\/a>, one of the regular and surely the most known blogger of SitePoint, I discovered that StatCounter report an usage of 1.4% for IEMobile (no distinction between versions). Therefore, having the @font-face<\/code> rule inside the @media<\/code> query, we’re achieving our goal of having a basic font at least for the 98.6% mobile users.<\/p>\n
    Craig also wrote me that NetMarketShare report shows 1.31% usage for IE9 and 1.0% for IE10 mobile<\/a>. Of course statistics can vary a little from site to site but we got the general point.<\/small><\/p>\n
    Now, let’s take into account the two major versions of Internet Explorer for mobile: 9 and 10.<\/p>\n
    As we’ve seen in a previous section, we’re targeting IE10 using a JavaScript code that uses an hack and test for the window’s width. If the device has JavaScript enabled, being the window’s width less than 980px, the fonts.min.css<\/code> stylesheet will not be added. Otherwise, if JavaScript is disabled, the snippet won’t run and the custom font won’t be loaded or set. Thus, our goal is achieved.<\/p>\n
    About IE9, there isn’t much to do: the stylesheet will be loaded and the custom font applied anyway. However, this issue should affect no more than the 50% of those using IEMobile.<\/p>\n
    To wrap up, the font is not<\/em> applied in roughly the 99.5% of the cases<\/strong> with a fail only on IE9. A big success.<\/p>\n
    Desktop Users<\/h4>\n
    As for the previous section, let’s have a look at the last statistics (June 2013) about desktop browsers usage<\/a>. The desktop statistics are the following:<\/p>\n