Font Awesome Issue


In my post Action Column Bug I was pointing out errors encountered when using Font Awesome loaded via CDN and then used in an action column.

Working through the issue with Sencha support I discovered what the actual issue is. Frankly it is both loading the CDN and Sencha Ext JS.

Now to explain, first I forgot my Font Awesome kit was using SVG, not WebFonts. Second, I didn’t read the release notes on Ext JS 7.0. In 7.0 Font Awesome included with Ext JS was upgraded from version 4.7 to version 5.6. Both versions are the Font Awesome “Free” icons.

Coming with the release of Font Awesome 5 was introduction of SVG font icons; rather than just the WebFont (image) version. This change gives me the idea in the future we may see WebFonts leave Font Awesome as SVG is much more robust and scalable than image based WebFonts.

To refresh memories on what error was generated, “Uncaught TypeError: target.className.match is not a function” occurs on ext-all-rtl-debug.js line 236543:49.

Debugging the issue with Sencha support I dug into the HTML of what was actually developed from code being written.

First step in debugging was removing my CDN inclusion of my commercial Font Awesome kit. Once removed it allowed me to discover what generated HTML was expected using the Ext JS built in Font Awesome 5.6. So the default generates this HTML for iconCls: ‘fas fa-edit’.

<div tabindex="-1" role="button" class="x-action-col-icon x-action-col-0 fas fa-edit" dat-qtip="Edit User" tabindex-value="0" data-tab-index-counter="1"></div>

You can see here there is clearly CSS definitions for .fa, .fas and second definition for .fa, .fas, .far, .fal, .fab. The HTML element is a div tag. The default generated HTML does not cause any errors, as we would expect due this being generated all from the Ext JS

Second I added my CDN Font Awesome back into the equation. This is where I both discovered I was running the SVG version and also the part I feel Sencha will have to address in near future release.

Here is the HTML generated by the SVG version of Font Awesome 5.14

<path fill="currentColor" more information></path>

You can see more detail about generated HTML in the above screenshot.

End result is the HTML with SVG is no where near what Ext JS is expecting to find in the element. Even if Ext JS picked up the path element there is no class definition at all, so the “fas fa-edit” is no where to be found; generating the error.

So clearly the “bug” is not supporting SVG version of Font Awesome.

I confirmed this was the issue by converting my Font Awesome 5.14 kit to use WebFont. The generated HTML is the same as is included with Ext JS. No errors and the handler is called correctly.

This leads us down why would Ext JS read a class name to determine what handler/function to send the click event to. Simply to understand, it is an icon, constructed from a CSS class definition, applied to a div tag. The class definition tells Sencha Ext JS what handler to read within the framework that the event should be sent to. So currently with an action column, used as designed by Sencha with icons, it requires the class to handle routing for the event to be passed to.

Technically Sencha is correct, this is not a “bug”. The SVG doesn’t fit within the requirements of the Ext JS framework and when using WebFonts it does work as expected.

Now from a developers stand, this is a bug. SVG icons are growing, they are more robust for resizing and offering us a great use without distortion. Many icon packages are moving to SVG because of this and several other reasons.

So reality, Sencha engineers need to evaluate the state of their product and if and when they would choose to support SVG icons within Font Awesome. Developers do pay for Font Awesome today and in payment most want to use the SVG versions and now can not with Ext JS.

I like the Ext JS framework and will be okay leaving my kit at WebFont for Ext JS; for now. I make this decision knowing I have lost some features of SVG and I will adjust my icon use sizing accordingly. But not all developers will want to take this route. Some will consider this a bug and taking away a third party feature we want to use in our product.

I will leave the debate to others if this is a “bug” or not. My vote fits with “bug” based on the above statement.


Author: aallord

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.