Minify lowercases CSS font-family declaration

[somratpro]

When I minify CSS, the font-family changed to lower case, and it caused an issue with font-awesome pseudo-elements. the font-family name should be in lower case, so it doesn't affect on pseudo-elements when we minify CSS. Here is a discussion happening on hugo forum https://discourse.gohugo.io/t/minify-lowercases-css-font-family-declaration/32581

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

I read the discussion on hugo forum

Could you please provide a reduced test case? It is not clear how you are using Font Awesome

We have a bug report template

[somratpro]

Hello @tagliala

Sorry for the late reply, I was out of town. I am using font awesome i2svg script, so when I minify my CSS, the font family name automatically generated to lower case. and then the browser didn't find the font family because the font family name should be capitalized. I see some configuration for font awesome script here. If you also add an option for the font family name lower case support, then the problem could be fixed. thank you.

[tagliala]

I am using font awesome i2svg script,

There are a lot of different ways to use Font Awesome. I guess this is an npm custom installation of the SVG Framework with some kind of custom CSS asset generation. Is that correct?

I think I got the issue (SVG Framework not performing case insensitive comparison as demanded by W3C Recommendation in conjunction with custom CSS minification), but before escalating the issue, could you please confirm or, better, provide a https://jsfiddle.net/ - https://codepen.io/ - https://codesandbox.io/ reproducible test case?

[tagliala]

Ok, let's be confident and escalate 😅

@robmadole

var FONT_FAMILY_PATTERN = /Font Awesome ([5 ]*)(Solid|Regular|Light|Duotone|Brands|Free|Pro|Kit).*/; // TODO: do we need to handle font-weight for kit SVG pseudo-elements?
/* [...] */
var fontFamily = styles.getPropertyValue('font-family').match(FONT_FAMILY_PATTERN);

This comparison should be performed in a case-insensitive manner, as per https://www.w3.org/TR/css-fonts-3/#font-family-casing

As part of the font matching algorithm outlined below, user agents must match font family names used in style rules with actual font family names contained in fonts available in a given environment or with font family names defined in @font-face rules. User agents must match these names case insensitively, using the "Default Caseless Matching" algorithm outlined in the Unicode specification [UNICODE].

emphasis mine

The issue may be caused by minifiers (like Hugo's one) that prefer to downcase the font-family value

The change is backward compatible and we can add the reference to the w3c specs to the changelog for clarity

[somratpro]

Here you go https://codepen.io/somratpro/pen/ZELgzqj

check CSS comments

[tagliala]

@somratpro thanks, it confirms what I've thought

[somratpro]

Then what should I do?

[tagliala]

Nothing else, thanks, just wait for the fix and the release of a new version

[robmadole]

Great catch! Thank you @somratpro. I've got the fix committed to both the 5 and 6 branches of Font Awesome.

[somratpro]

Thank you, can you please let me know, in which version we will get it working?

[robmadole]

@somratpro right now this will be included in the next version of 6. We don't have a release schedule for the next version of 5. (We are all-hands-on-deck working on version 6 right now)

[robmadole]

Ok, this has been fixed in 6.0.0-beta1. We will port the fix to 5 next.

[robmadole]

This has been fixed in 5.15.4.