Base64 Encoding Data URI can be used for Font Face in CSS Files, this is basically a good practice as we are decreasing four HTTP requests per font face. Redmond’s Browser (read Internet Explorer, if you never heard the terminology) can not be taken as a standard web browser, unfortunately. More unfortunately, it is still used and we still need to add the CSS, Javascript etc. fix for each version.
As practically most of these users are newer and the usage rate is declining very fast (historically, we should be thankful to Opera), may be you’ll think that probably there is no need to show the Internet Explorer users a very great Typography. Its important to know, depending on the user types of the website, you might need to think what is required to use. Peoples of China at the time of writing, still uses Internet Explorer 6. So, at least for commercial websites, it is quite important to show things properly. For non-Microsoft product, tutorial related blogs, honestly; you can ignore the fix and let the browser fall to the second closer font mentioned in the CSS file. In other words – if Internet Explorer users of the particular website historically is more, the time and money investment will be worthy (as market share is falling very fast).
Base64 Encoding and Font CSS : Introduction
For Free Fonts, there is no headache for the Licensing part. For paid Fonts, if you have the License, no one can prevent you to use the Font in Base64 Encoded Data URI format. It is quite important to understand that, Helvetica Neue Ultralight is quite closer at look when compared with Proxima Nova Condensed Thin. There is no issue with Mac, but for Windows PC, there can be issue, nicely discussed here :
1 | https://github.com/twbs/bootstrap/issues/3629 |
So, these are quite important points to consider in the context of Base64 Encoding and Font CSS. What fonts to use and for which purposes in blogs is a complicated topic itself. Image in CSS to Base64 Data URI and How To Use Any Web Font From Own Hosted Library. These last two links towards two guides are quite important in the context of Base64 Encoding and Font CSS.
Advertisement---
Base64 Encoding and Font CSS : Guide
So, our practical targets are two in number :
- To load the font properly for most of the users of the particular website for proper Typography
- To decrease the HTTP requests to load the webpage quickly
You’ll be using EOT for legacy IE and WOFF for anything else. Normally we use this typical CSS :
1 2 3 4 5 6 7 8 | @font-face { font-family: 'MyWebFont'; src: url('webfont.eot'); /* IE9 Compat Modes */ src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ url('webfont.woff') format('woff'), /* Modern Browsers */ url('webfont.ttf') format('truetype'), /* Safari, Android, iOS */ url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */ } |
When we are thinking about Base64 Encoding Data URI that can be used for Font Face in CSS Files, ideally we should use all the substitutes and replace with Data URI. But, practically this works :
1 2 3 4 5 6 7 8 9 | @font-face { font-family: 'Arial'; /* Do Proper Naming */ src: url('Arial.eot'); /* For IE 5-8 */ src: local('?'), /* It is called smile hack to promote CSS to UTF-16 */ url(data:font/truetype;charset=utf-8;base64,) format('truetype'), /*base64 encoded font IE9, Safari 3.1+ FF 3.5+ Chrome 4.0+*/ url('Arial.svg#123XYZ') format('svg'); /* iPad, iPhone with OS less than or equal to 4.1 */ font-weight: normal; font-style: normal; } |
If you do not add the eot and SVG, actually it will fall back to second option – Helvetica Neue Ultralight will not create issue for iOS users, OS X users. They are installed by default plus the thing is for older generation. Now about generation. Almost all paid Font “suppliers” now has kits or tools for the automated Base64 Data Encoded CSS for Font face. For Free Fonts, you can use this tool :
1 | http://www.fontsquirrel.com/tools/webfont-generator |
You can use a TTF font and generate the whole thing kind of automatically.
