title: Embedded fonts versus an external resource
body: <p>I have been tackling the problems of Webfonts across various browsers, and have been following the <a href="http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax" rel="nofollow">recommendations of FontSpring</a> that seems to be the latest recommended solution.</p>
  
  <p>However, as I am using a CDN and serving up my CSS files from a different domain, I very quickly discovered that neither IE or Firefox will load the WebFonts from the CDN giving an error such as <code>@font-face failed cross-origin request</code>.  In my CSS I had something like the following:</p>
  
  <pre><code>@font-face {
      font-family: 'ClarendonRoman';
      src: url('/assets/fonts/clarendon-bt-webfont.eot?#iefix') format('embedded-opentype'),
         url('/assets/fonts/clarendon-bt-webfont.woff') format('woff'),
         url('/assets/fonts/clarendon-bt-webfont.ttf')  format('truetype'),
         url('/assets/fonts/clarendon-bt-webfont.svg#svgFontName') format('svg');
      font-weight: normal;
      font-style: normal;
  }
  </code></pre>
  
  <p>As you can see, the paths to the fonts are relative to the CSS, and as a result fonts won't load from the CDN.  What I have had to is hard code in the domain of the site into my style sheets so that the fonts do load from the same origin.  So my new style sheet looks like this:</p>
  
  <pre><code>@font-face {
      font-family: 'ClarendonRoman';
      src: url('//mydomain.com/assets/fonts/clarendon-bt-webfont.eot?#iefix') format('embedded-opentype'),
         url('//mydomain.com/assets/fonts/clarendon-bt-webfont.woff') format('woff'),
         url('//mydomain.com/assets/fonts/clarendon-bt-webfont.ttf')  format('truetype'),
         url('//mydomain.com/assets/fonts/clarendon-bt-webfont.svg#svgFontName') format('svg');
      font-weight: normal;
      font-style: normal;
  }
  </code></pre>
  
  <p>And now with the embedded domain, everything works perfectly across HTTPS and HTTP traffic.  However, I am not entirely happy as I am no longer using my CDN to serve up the font files, and I am a stickler for performance.  As I can't seem to get around the cross origin domain issue, I have been thinking about embedding the fonts instead.  If you take a look at <a href="http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax" rel="nofollow">http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax</a>, you will see that they recommend a data-uri embedded format as follows:</p>
  
  <pre><code>@font-face {
    font-family: 'MyFontFamily';
    src: url('myfont-webfont.eot?') format('embedded-opentype');
    }
  
  @font-face {
    font-family: 'MyFontFamily';
    url(data:font/truetype;charset=utf-8;base64,BASE64_ENCODED_DATA_HERE)  format('truetype'),
    url(data:font/woff;charset=utf-8;base64,BASE64_ENCODED_DATA_HERE)  format('woff'),
    url('myfont-webfont.svg#svgFontName') format('svg');    
  }
  </code></pre>
  
  <p>So I have quite a few questions about this:</p>
  
  <ul>
  <li>Surely if I embed the font twice in my stylesheet using Base64 encoding for the TTF and WOFF formats I am going to bloat my style sheet to the point where possibly the advantage of embedding is negated by the doubling or more of data in my stylesheet?</li>
  <li>Why in the example is src: not used before each url(data:...).  Is this a typo, or intentional?</li>
  <li>If I embed the fonts, will all browsers use the embedded version over the EOT version and thus save a server round trip?  Which browsers will use the embedded TTF or WOFF files?</li>
  <li>Why are we not embedding the EOT version?</li>
  </ul>
  
  <p>I appreciate there's quite a bit in this post, but I am hoping this post will prove useful to others who face the same dilemma.</p>
  
  <p>Matt</p>