Font-awesome: Embed font files as base-64

[davegandy]

What do folks think about base-64 encoding all of the font files and including them directly in the LESS and CSS? There are apparently implementations that will also work in IE7.
http://venodesigns.net/2010/06/17/you-got-your-base64-in-my-css/
http://stackoverflow.com/questions/1124149/is-embedding-background-image-data-into-css-as-base64-good-or-bad-practice

Advantages:

• No messing with font path, everything could be implemented in a single css file.
• Should be no funky cross-domain font loading issues in Firefox and others. Font files will get served in their proper format.

Thoughts?

[nextgenthemes]

I did not know that this is possible with fonts. I know this for images. Well you save a http request but the actual filesize get a little big bigger for base64. I guess it's a good idea but i know not enough about it to say this is my final opinion.

[kremalicious]

I would say no. Saving 1 http request but giving users exceptionally more data than they need isn't a good approach. In the current implementation the browser makes 1 http request for the font and downloads 1 font file. If we base64 encode all the font files, users will get the data for all the different font files, not just the one their browser needs. To me, the saving of 1 http request doesn't justify this. And the initial rendering of the page will take longer because it won't start before the bigger CSS file gets downloaded. Currently the page gets rendered fast with the icons coming in afterwards.

The other problem I see is caching. If you include the fonts within the CSS they won't get cached anymore and there're some file size restrictions in place on mobile devices for cached resources, although I'm not sure if this is still valid for newer OS.

Nevertheless, this could be added to a best practice section in the docs because for some larger projects this could improve performance. E.g. when a page loads many more font files, embedding at least the icon font could be a good idea.

[replete]

I don't think there is benefit in delivering much more data to everyone, to save just one HTTP request and eliminating easily-solved MIME type font issues.

You can save a request simply by including the fontawesome.css within their main stylesheet, e.g. by a LESS import, or some build-script concatenation.

[nextgenthemes]

@kremalicious Yes i agree i not taught about that this way all font files would be delivered to everyone. The usual way seems to be better because the browser just picks the font its supports and don't even loads the others.

[yannski]

However, when you host your font on Amazon S3, you have no other choice that base64 encode them (because S3 does not support the correct HTTP header for cross domain font serving). So having an example using base64 could be really nice.

[auxbuss]

I'm in favour. It's solved problems on some devices going this route with some other fonts.

[davegandy]

Yeah, I won't be doing this by default. If folks want to take the font into Font Squirrel, it will Base64 encode the fonts. Not a bad solution if you need it.

[padde]

This would still be useful if you want to keep the fonts in the browser cache with a cache manifest (won't work with standard font files)

[xero]

sorry to comment on a closed issue, but im working with font-awesome on the amazon cloud which is messing up font headers for firefox only (weird right?). so i tired the base64 encoding trick and it works like a charm! for thoese who are interested, i uploaded the ttf to the font-squirrel webfont-generator, selected expert mode, set the css to base64 encode, and selected a custom sub-setting with a unicode range of xf000-xf112. bam. works perfectly. but i think the css that font-squirrel sent me is a bit verbose. is there a better way to do it than....

@font-face {
    font-family: 'FontAwesome';
    src: url('../font/fontawesome-webfont-webfont.eot');
}
@font-face {
    font-family: 'FontAwesome';
    src: url(data:application/x-font-woff;charset=utf-8;base64,[BASE64_DATA_GOES_HERE]) format('woff'),
         url('../font/fontawesome-webfont-webfont.ttf') format('truetype');
    font-weight: normal;
    font-style: normal;
}

i really want to combine the two style declorations into one, but im pretty sure the order is important. also the #iefix from the base css is missing. suggestions are welcome.

[matzke]

+1 for base64 (as optional alternative)

I would like to use fontawsome in wicked_pdf (wkhtmltopdf), where i would have to use base64 encoding.

[miere]

+1 for base64 (as optional alternative)

[jedibatman]

To those interested I have forked the 'font-awesome-rails' gem to include an optional css file that has the font base64 encoded, for your wkhtmltopdf pdf generation needs.

https://github.com/Outcome-Engenuity/font-awesome-rails-base64

Let me know if anyone has any issues with it, or if you would like additional features.

[eduardoinnorway]

Fonts is a pain in the ... some times, so a base64 alternative is a big +.
The so called "size increaze monster" is a drop in the air for this case and font. To let the user wait a millisecond more or less to see an icon is a better solution than to show null just because you have no means to mix with the server. So please, pritty please with sugar on top, a base64 alternative.

[antoniobrandao]

+1

[Spangenhelm]

+1 Sorry for commenting on a closed issue but having a base64 version is really useful within certains applications like for example TiddlyWiki (a single self-modifying html file that can be used on or offline. my interest for the base64 embedded fonts comes from the fact that i can store all my datas and the app itself within one single html file !)

If it is not too much work for you then we would really appreciate it !
Thank you

[adamwintle]

<rant>In mainland China its a real pain because the Chinese government partially blocks some website's HTTP requests. It seems like they block certain files (PDFs, fonts, .ZIP), etc and not just the entire websites. This problem isn't even consistent to one region of China either; in Beijing we can't load web fonts (from what we think is the local ISPs blocking some western web fonts) and in Shenzhen all web fonts load without a problem.</rant>

So yeah, it would be great if a reliable base64 version was included in the official repo instead of using third-party tools. This way its one less HTTP request and its all bundled into a CSS file, which makes the content of the font harder to trace.

[stef-w]

+1

[nextgenthemes]

You can always write a script that pulls the current woff from this repo and generates a css with the base64 font in it.

Even If I not use FA any more but +1 from me for having this in the repo. Funny how much learned since 2012.

[wavded]

+1

[tobibeer]

I sure wish the base64 string for the woff was part of the distro, because figuring out a tool to do the conversion can be ...difficult.

[stefanct]

+1 because it would make creating self-contained html files (e.g. with asciidoctor) way easier. i can't remember reading that argument yet...

[morganfeeney]

Wouldn't this also be a good way to avoid issues with screen readers reading out the glyph character? This solution just means an icon is only that.

[tagliala]

@morganfeeney I may be wrong but this should have no effect on screen readers. Screen reader compatibility should be addressed in the docs here: http://fontawesome.io/accessibility/

[morganfeeney]

What I was getting at is that you wouldn't need to add the markup to hide characters from screen readers. A CSS only solution would just rule it out completely as you wouldn't assign an icon to a character. Would it not?

[tagliala]

I don't know if embedding fonts as base64 would prevent screen readers to read glyphs. We had a discussion on accessibility at #6133 and nobody mentioned this approach.

Moreover, I'm strongly against this because embedding all formats in the .css file will force the browser to download them all (.eot/.woff//.woff2/.svg), instead of picking the most appropriate one

[ranbuch]

+1
I need to convert an SVG with Font-Awesome text to image. To do that I (to my understanding) need to embed inline font into the SVG, otherwise the font-face wouldn't be supported.

[alexbruno]

I just published an alternative solution for this problem:

https://www.npmjs.com/package/font-awesome-base64

[svyatik]

There's one good solution for base64 fonts. You can download them async, separately from your main css file. Then you can save these base64 fonts to localStorage and apply from async JS to every page. This will give you a big boost of website loading.