While using SVGStore to automatically create svg icon sprites, I ran across an issue where SVGStore would break any SVG filters contained in the image file.  

My current workflow is to export from Illustrator (using the great new Asset Export feature) into a folder. Grunt then sees the changes and runs SVGStore to create a single SVG file, ready to be used with, uh, <use>.

However, if you export from Illustrator using either the “Internal CSS” or “Inline Styles” export options, you’ll find that any styles that reference filters embedded in the SVG will not be applied. 

This is because SVGStore changes the IDs of both paths and filters within the SVG file but does not change the referencing IDs within the CSS, which is the glue that holds the paths and the filters together. 

As a workaround, I’m now using the “Presentation Attributes” export option within Illustrator and this does seem to work. 

There is an outstanding issue which talks about a similar problem. 

Grunticon and WordPress

The default Grunticon setup creates standard CSS files, which contain selectors for you to use in your HTML (e.g. .icon-read-more { /* Image data */ }). 

However, I’m building a theme for WordPress and I can’t always get at the HTML easily to drop in the default generated classes. 

 For example, the Read More link is automatically generated in the loop when the_content("My Read More Text") is called. You can override this with a WordPress filter, but it seems overkill to have add a filter in the “functions.php” file just to add a class to a tag.

So instead I now have Grunticon output the fallback CSS to my SCSS build folder instead, rather than directly to CSS as in the default setup. I also created a custom Handlebars template that looks like this:

${{name}}:  '{{datauri}}';

This is a SASS variable, ready to use, which appear in the three partials that Grunticon generates, “_grunticon-data-png.scss” ($icon-read-more:  'data:image/png;base64…';), “_grunticon-data-svg.scss” ($icon-read-more:  'data:image/svg+xml;base64…';), and “_gruticons-fallback.scss” ($icon-read-more: 'path/to/fallbackImage.png';).

Any selectors that need to apply a generated background image go in a fourth, separate partial (“_grunticons.scss”):

.more-link {  
    background-image: $icon-read-more;  
}

I then import this partial along with “_grunticon-data-svg.scss” into my main “style.scss” file:

@import "grunticon-data-svg";  
@import "grunticons";

This generates the CSS using SVG data. If a fallback is going to be necessary, then I also have two more SASS files that generate my fallback CSS (“icons.data.png.scss” and “icons.fallback.scss”), which look like this:

@import "grunticon-data-png"; /* Or "grunticon-fallback"  */  
@import "grunticons";

This then generates the final “icons.data.png.css” and “icons.fallback.css” files ready to be loaded in by the Grunticons detection script should a fallback be required. I used Chris Coyier’s Inline SVG with Grunticon Fallback to decide if the Grunticon script should run.

The downside of this approach is that everyone downloads the SVG whether they get to use it or not, and if their browser can’t display SVGs then they might then have to download an additional stylesheet with one of the two fallbacks. 

I could separate out the SVG file further and let the Grunticon javascript snippet decide on that too (as it does by default), but based on our usage statistics the vast majority of our users will not need either of the fallbacks and so I decided that saving an extra network request by embedding the SVG data directly into the main stylesheet file was better for the majority of our users.

It’s only now, reading this back, that I realise perhaps adding a filter to “functions.php” to add a class name maybe isn’t overkill after all (why get actual work done when you can tinker with a workflow?).