Currently, S4649 “Unexpected missing generic font family” is triggered when icon fonts are used in CSS.
This rule makes sense for text, but does not for icons. It would be nice if this issue could be suppressed for known icon fonts, without turning it the rule off completely.
stylelint has support for this already, but there’s currently no way to pass that setting through that I’m aware of.
Personally, instead of supporting a custom field that will not often customized, I would prefer that out of the box S4649 ignores font-family when it’s used in the context of icon fonts.
Today, I see two options:
hard code a list of well known Icon Fonts (“Font Awesome*”, …) but that would be complex to keep it up to date
find a way to determine that no issue should be raised if this or that other field is there. For example, if font-family is defined without any generic font family but with a content field, then nothing should be raised.
Do you see a better way to determine that a CSS block is related to an Icon Font?
Yes, your screenshot is a great example of this scenario.
I agree that a hardcoded list isn’t a great solution.
Unfortunately, I don’t see a good heuristic for distinguishing between an icon font and other custom fonts. For non-icon fonts, even if there’s an @font-face block specifying a custom src, applications should still specify a generic fallback in case the browser wasn’t able to load the font. I’d rather have the false positives (that I can disable from te UI) than that potential false negative!
Is the list of “well known Icon Fonts” available for viewing somewhere?
Upgrading to the newest version of glyphicons (as opposed to it being included in older versions of bootstrap) has caused the font-family of “Glyphicons Halflings” to be flagged.
I am also looking for a list of the “well known Icon Fonts” for the same reason as Sean - Glyphicons Halflings. I’d usually just +1 something like this but since it’s been 3 months since they posted, I figured it might need to get pushed back to the top of the pile.
