A several years ago I started building a little PWA and chose Bootswatch 3.3.5. for theming. As it depends on Bootstrap I was able to use the icons from Bootstrap. At the beginning I needed only a handful of these icons, but with the time it became more and more difficult to find the right one, because the Bootstrap Glyphicons in version 3 included only around 250 icons and there was not always the right one. Also, the app was always lugging around well over 100 KB of extra files, of which I actually only needed a few kilobytes.
In another project I had used Fontello, where you can build and download your own icon font from a selection of available icons. Very nice, but I didn’t feel like fiddling with project-specific configuration files on the Fontello website. But since you could upload your own SVG files in Fontello, which were then taken over into the font, the same had to work somehow with a Node.JS plugin!?
Just copy a bunch of SVG files in a folder, run gulp and there was my own customized icon font with a tolerable size of around 20 kilobytes. At that time, Thomas Jaggi had taken care of the creation of a CSS file with the correct code points that matched the font with his tool gulp-iconfont-css.
First I needed some SVG files…
… and the NPM packages of my task runner gulp.js:
npm install --save-dev gulp-iconfont
For generating the CSS file a template called
_icons.css is shipped with the NPM package of gulp-iconfont-css, which can be customized as needed. In my case I just made a copy into a folder called
Templates, where I store all other template files I need for my PWA.
As I was using Gulp for building my app, I had to integrate a new task for creating the icon font in the
var iconfont = require('gulp-iconfont'),
I little explanation on that … First of all the task for gulp-iconfont-css has to be inserted before piping the files through gulp-iconfont, in order to create the CSS file properly. Following options were used:
||Name that the generated font will have|
||Path to the template for generating CSS file|
||Path where the CSS file will be generated|
||Path to the icon font file|
||Font file formats that will be created|
||Name of the font (for svgicons2svgfont)|
||Minimum height on scaling icons|
||Normalize icons by scaling them to the height of the highest icon (for svgicons2svgfont)|
||Prefix files with their automatically allocated unicode code point (for gulp-svgicons2svgfont)|
||Get consistent builds when watching files (for gulp-svg2ttf)|
gulp build all files needed were generated:
All I had to do now, was to reference the new CSS file in my HTML and decorating my HTML tags with one of the new
icon-classes. Yes! My had my own icon font, just by copying some SVG files in a folder…
A while later, as my app grew, I needed some new icons, but in the meantime I had used the content codes elsewhere in static CSS files, for example with other pseudo-selectors like AFTER.
After copying a few new icon files to the SVG folder and running the build, I found that most of the icons didn’t fit anymore!?
After a short research it was clear to me what had happened. With the insertion of the new SVG files, the order of the files in the folder was changed. But since the libraries processed this folder in alphabetical order, file by file, and simply incremented the codes to be assigned, the codes had simply shifted.
In the example above, this can be easily understood if we insert a file named cloud.svg here. The code for cancel.svg (
E002) remains untouched, but cloud.svg now gets
E003 and delete.svg
E004 and so on. The hardwired icon for
E006) now showed instead of the link icon a flag icon.
I don’t know when this happened, because I don’t keep a constant eye on my little PWA and thus the further development of the related tools, but after having manually adjusted the moved codes two or three times now and once again wanting to change a few things on the PWA’s icons, I had enough and came across the following sentence on the gulp-iconfont-css page on GitHub:
--- backflip (Thomas Jaggi)
Recent versions of gulp-iconfont emit a glyphs (or codepoints < 4.0.0) event (see docs) which should likely be used instead of the workflow described below. However, it will continue to work as expected.
Ahh, ok. I don’t need the gulp-iconfont-css anymore. I can create the CSS file by myself. Lets see how the gulp-iconfont task looks, after rewriting:
var iconfont = require('gulp-iconfont');
First I have introduced a new
fontObj variable to hold all informations for the untouched CSS template. The major difference is now, that
iconfont is the only main task, with a subtask where the glyphs are processed directly via
mapGlyphs() function ensures that the file names with the CodePoints are transferred into an easily usable structure.
Works fine, but doesn’t solve my problem with the shifted CodePoints, when inserting new SVG icons … but someone remarked in a StackOverflow article to have a look at the test files of gulp-iconfont. There, the SVG files carry as prefix the name of the CodePoints to be used for this file!. Unfortunately, this feature is not documented, but it works…
Now the order of the SVG files doesn’t matter anymore. I just copy a new SVG file into the folder and rename it with a currently unused Unicode.
Interestingly, the inventor of gulp-iconfont page writes on the GiHub page:
--- Nicolas Froidure (nfroidure)
Warning: While this plugin may still be useful for fonts generation or old browser support, you should consider using SVG icons directly. Indeed, when i created gulp-iconfont and all its related modules, using SVG icons was just not realistic for a wide browser suppport but i was already conviced that SVG was the future, that’s why i wanted my SVG source files to sit separated in a folder. So, now, just enjoy switching to SVG with almost no effort :). Was a great open source journey with you all!
This goes along with some older articles of Chris Coyer from CSSTricks:
Maybe it’s time to say goodbye to icon fonts completely and use SVG files directly, but in my opinion this is not suitable for all needs. Especially if you work a lot with pesudo selectors, a general rebuild of the code and the UI will be necessary and you would do well to weigh the cost-benefit carefully.
You can interact with this article (applause, criticism, whatever) by mention it in one of your posts or by replying to its syndication on Twitter, which will also be shown here as a Webmention ... or you leave a good old comment with your GitHub account.
No Webmentions yet...
In case your blog software can't send Webmentions, you can use this form to submit me a mention of this article...