Support FontAwesome 6 classNames - #776
Conversation
|
Shouldn't we support both versions? |
|
Thanks for this, and sorry it sat so long. Answering the "shouldn't we support both versions?" question: yes, and I've opened #821 which supports 4, 5, 6 and 7 together. Two reasons I went with a fresh PR rather than building on this one. Enumerating styles is a losing game. v7 keeps adding packs, each with its own short prefix. The docs list Renaming Your diagnosis was right, and #821 fixes the case you identified plus three more that were also broken: One thing worth flagging, since it is the trap here: Since this branch is also a few versions behind |
* feat: support Font Awesome 4 through 7 icon syntax
Font Awesome renames a style in every major version:
v4 <i class="fa fa-user">
v5 <i class="fas fa-user">
v6 and v7 <i class="fa-solid fa-user">
<i class="fa-sharp fa-solid fa-user">
<i class="fa-sharp-duotone fa-solid fa-user">
Detection only knew v5's five short prefixes and v4's shorthand, so on current
master:
"fa-solid fa-user" -> <i class="fa fa-solid fa-user"> stray `fa`
"fa-sharp fa-solid fa-user" -> <i class="fa fa-sharp fa-solid fa-user">
"fasds fa-user" -> context-menu-icon-fasds on the item, no icon
"fa fa-user" -> context-menu-icon-fa on the item, no icon
The stray `fa` is not harmless: in v6 and v7 it is a legacy alias that sets the
solid font-weight and the Free font-family, so it competes with `fa-regular`
for weight and with `fa-brands` for family, and which one wins depends on
stylesheet order.
Rather than enumerate versions, which is what put us here, ask the two
questions that actually matter. Is this Font Awesome at all, i.e. is there an
`fa-*` token? And does the class list already name a family/style, or does v4's
base `fa` need supplying? Short prefixes are matched by shape
(`fa`, `fas`, `fass`, `fasds`, `fands`, ...) rather than from a list, so the
packs v7 keeps adding need no change here.
Backwards compatibility. Of 147 unit tests, exactly 4 change behaviour and 143
are unchanged, all four being the broken cases above:
* v4 shorthand `fa-user` still gets `fa` supplied, and so does the modifier
form `fa-user fa-lg`, which relies on it to render at all. Nothing in either
list names a family, so the old behaviour is exactly preserved.
* v5's `fas`/`far`/`fal`/`fad`/`fab` are byte-identical to before.
* Built-in icon names are untouched. Detection keys off an `fa-` token rather
than a bare `fa…` prefix specifically so a short custom name such as
`icon: "fav"` is not swallowed.
* `--fa5` is still the class emitted on the item. Renaming it to `--fa6`, as
the original patch in #776 did, would break any custom CSS matching it, and
the marker was never version-specific: it is just the hook the stylesheet
uses to position the child icon.
Refs #776.
* refactor: drop the regex from Font Awesome detection
Review feedback: the previous commit claimed not to enumerate versions, then
buried an enumeration inside a fuzzy pattern:
/^(?:fa[a-z]{0,4}|fa-(?:classic|sharp|sharp-duotone|duotone|solid|regular|light|thin|brands))$/
Two simplifications make it unnecessary.
A short prefix never contains a hyphen. `fa`, `fas`, `fasds`, `fands` are all
hyphen-free, while icon names and modifiers (`fa-user`, `fa-lg`) always have
one. So telling a prefix from an icon name needs no list, and the `fa[a-z]{0,4}`
guesswork goes away with it - along with its false positives on words like
"fancy".
Only the styles need listing, not the families. Version 6 and 7 always name a
style next to the family, so `fa-notdog-duo fa-solid fa-user` is recognised
through its `fa-solid`. A family added after this code was written needs no
change, which is what the pattern was reaching for in the first place. Added a
test for exactly that case.
What is left is a padded string of nine class names and two `indexOf` checks.
The only remaining regex is the `split(/\s+/)` that tokenises the class list.
The padded-string form also avoids an icon named "constructor" matching
Object.prototype, which an object lookup would have.
No behaviour change: 143 of 148 tests are unchanged against master, the same
set as before, and the 5 that differ are the previously broken syntaxes plus
the new unlisted-family case.
|
Thanks for your work, and for providing the extensive reasoning behind your decisions. |
2 participants
Update FontAwesome-icon check to detect new FontAwesome icon styles introduced in v6