Font-awesome: remove old font formats

[DanielRuf]

In favor of WOFF and WOFF 2 it makes sense to deprecate and remove the old font formats in the near future to improve loading times.

http://caniuse.com/#feat=woff
http://caniuse.com/#feat=woff2

[tagliala]

Hi, nice suggestion.

So IE8 support requires .eot, but .eot is also used by IE9 when the .woff format is missing its mime type on some (old?) IIS servers. So it has still reason to exist.

We are using Fontsquirrel's webfont generator, as suggested by Bulletproof @font-face Syntax

Maybe it is time to change something in the font face declaration but I don't know if FA 5.0 will do some R&D on this

[DanielRuf]

Which IIS servers have this issue?

At least it is widely recommended (also in boilerplate server configurations) to add the mimetypes to the server configuration to prevent such problems. In this case this is server related (possibly misconfiguration) and should not prevent the usage of WOFF imho.

[tagliala]

@DanielRuf Sorry but I don't know exactly, it appears to be 5.0 and 6.0.

I've just did some searches in trying to understand why .eot is still used and why IE9 could possibly prefer that to .woff, since it is supported. .eot could be just a fallback for misconfigured web servers. As I said, those articles are quite old, maybe a proper report on today's most used webservers and their default configuration could help

[DanielRuf]

maybe a proper report on today's most used webservers and their default configuration could help

This would be definitely helpful to find and document problematic configurations and evaluate their impact on this.

[jbblanchet]

What would be most useful for us is to be able to control the included formats from a variable in the _variables.scss file, so we could customize the formats in our builds.

[tagliala]

@jbblanchet you could provide your own _path.scss

/*!
 *  Font Awesome 4.7.0 by @davegandy - http://fontawesome.io - @fontawesome
 *  License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License)
 */

@import "variables";
@import "mixins";
@import "mypath"; // <--
@import "core";
@import "larger";
@import "fixed-width";
@import "list";
@import "bordered-pulled";
@import "animated";
@import "rotated-flipped";
@import "stacked";
@import "icons";
@import "screen-reader";

[jbblanchet]

@tagliala But that would mean updating the file inside the node_modules folder, which I don't want to do, for obvious reasons.

By contrast, if there was a $fa-formats variable in the _variables.scss file, I can simply define it first in my own file, then import the font-awesome.scss file, and everything would work out, because of !default. No need to overwrite the content of node_modules. Updating the version through npm would still work.

[DanielRuf]

@tagliala But that would mean updating the file inside the node_modules folder, which I don't want to do, for obvious reasons.

By contrast, if there was a $fa-formats variable in the _variables.scss file, I can simply define it first in my own file, then import the font-awesome.scss file, and everything would work out, because of !default. No need to overwrite the content of node_modules. Updating the version through npm would still work.

Right, this could be problematic when using the bundled packages with bower, npm and other solutions.

[jbblanchet]

@DanielRuf Exactly.

Maybe I could explain a little bit the workflow we have. We have a react app built through Webpack. Font-Awesome is installed through npm, and the .scss file is imported from the app root. Then there's a webpack url-loader for the woff that inlines the the font in our css bundle. Woff being supported by all the browsers we support, it's really the only one we need. The 27kb difference with the woff2 file is not significant.

Problem is, since the woff2 is listed, browsers that support woff2 will download the file since it's preferred to woff, even if the woff is inlined.

So having the ability to update a variable and only link the formats we need would help support such a scenario, and offer some flexibility.

I feel like this is related to your issue, but if you prefer that I open a separate one, let me know.

[tagliala]

@jbblanchet thanks for explaining this.

Please start a new issue. Such a feature could also help while developing (if you take a look at the source, there is a commented-out .otf)

[DanielRuf]

Maybe I could explain a little bit the workflow we have. We have a react app built through Webpack. Font-Awesome is installed through npm, and the .scss file is imported from the app root. Then there's a webpack url-loader for the woff that inlines the the font in our css bundle. Woff being supported by all the browsers we support, it's really the only one we need. The 27kb difference with the woff2 file is not significant.

We had the exact same scenario and decided to manually include the files and just include the .woff file but this makes it harder to update the thirdparty assets by running npm update.

[jbblanchet]

Done: #10478. Thanks.

[DanielRuf]

Bump.

[gchiaren]

Sorry to bump an old thread, but I was wondering the same thing recently. I have a new project where I'm using Font Awesome 5 and hosting the fonts myself. Site speed is a big concern so I am only hosting the following formats:

• eot
• woff
• woff2

Is that generally a best practice for Font Awesome for speed and majority coverage?

[tagliala]

Hi @gchiaren

Feel free to customize Font Awesome' s font-face property to the best value that fits your needs

If your browser supports woff2, it will not download neither eot nor woff. Removing font formats for browsers that your application does not support will save some space from the css file and less than 1MB on your webserver space, nothing more.

Is that generally a best practice for Font Awesome for speed and majority coverage?

Depending on your use case, you can consider using the SVG framework and the built-in tree-shaking feature of webpack. In this way, you will bundle with your javascript assets just the icons you need

Docs:

• https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking

[DanielRuf]

woff + woff2 should be sufficient. See the support tables on caniuse.com.

[tagliala]

@DanielRuf thanks again. We will certainly reconsider the fonts to include in the next major release of Font Awesome