Add gulp and grunt functionality to generate sprite sheets

[Rumyra]

https://github.com/jkphl/gulp-svg-sprite

[pixeltherapy]

When you say sprite sheets, do you mean:
a) a single file containing all SVG's as symbols? Such as https://css-tricks.com/svg-symbol-good-choice-icons/
b) a generated HTML file showing the icon and corresponding code? Such as http://fontawesome.io/icons/
c) both? :o)

[Rumyra]

I've been thinking a bit about what to do with these SVGs to make then more useful for builds...

https://24ways.org/2014/an-overview-of-svg-sprite-creation-techniques/

There are three main techniques here:

1. An SVG file with each defined as a to be referenced
2. A CSS class for each (included as data in the CSS) that can then be referred on the element
3. The sprite sheet (Your option 'a' @pixeltherapy)

Each of them have their own pros and cons. And with each you'd need a good way of keeping them up to date with the master Font Awesome.

So if we start with method 3) - maybe a using the link above, a gulp script to take the SVG folder and generate a sprite sheet of all the icons.

A nice to have would be an easy way to reference them (this is a little trickier perhaps and I think where your option 'b' could come in @pixeltherapy ).

Does that make sense?

[pixeltherapy]

I guess it depends on who this resource is targeted at and the type of workflow it will fit into. There's merit (imho) if it can be simply included in a project and used right away without needing to add it to a build system. Bonus points if it can be included and used as easily as Font Awesome is.

My preferred method for including SVG icons is with <symbol> and use but this likely isn't very 'CDN-ifyable'.

In any case, the tool of choice would seem to be https://github.com/jkphl/gulp-svg-sprite with the output from font-blast as the source. You could also just use the Node module https://github.com/jkphl/svg-sprite but being a Node noob I can only offer my gulp services!

Let me review your linked article from Sara Soueidan * hat tip * and configure a gulp task to develop the idea a bit more.

[Rumyra]

Yes it absolutely does and maybe I'm trying to blanket al use cases and maybe just starting with one is enough.

I absolutely agree whichever use it's needed in the simpler to 'just include' the better.

Gulp help is much appreciated, I haven't extensively used it :) I can however cover node. I apologise in advance if I'm late to help with anything I am away travelling as of next week for this month, but I will do my best!

[pixeltherapy]

I'm having a look at it this morning and my first speed hump is on project structure. I wanted to get your input before going much further as there are two different directions to go in depending on what the goal of this project is.

As I see it, the goal is to use font-awesome-SVGs in a project instead of font-awesome. I also think it might just be possible to build it in a way that allows the end-user to just swap font-awesome for font-awesome-SVGs without changing their markup.

At the moment you have a fork of font-awesome, which means you can/should only add features to the code base while also (preferably) following the coding standards and using tools already established. Building on this with font-blast and svg-sprites Node modules fits well with a fork of font-awesome, extending the build to also create SVGs.

Adding gulp/grunt to the fork seems a bit hacky. For example, with this fork there is already a packages.json for the font-awesome project. Adding a build system for using gulp-svg-sprites would mean hi-jacking the font-awesome packages.json and muddying the intent of the code. Also, why include the entire source for font-awesome when only the distributed font files are needed?

So, unless I just got out the wrong side of the bed today, that leaves a few directions to go in:
A: Maintain the fork and build on it with Node modules, ignoring gulp/grunt altogether, or
B: Start a clean repo for a Node build with font-awesome as a dependency, again ignoring gulp/grunt or
C: Start a clean repo for a gulp/grunt build with font-awesome as a dependency and, when someone writes a gulp-wrapper for font-blast, add it to the gulp build.

I would lean towards plans B or C as you would end up with a build system that could take any icon font and package it nicely as SVG for inclusion in a project. Plan B doesn't need me but it does give me an opportunity to pick up some Node chops.

What are your thoughts? Am I just showing my Node noob-ness? ;o)

[Rumyra]

This is amazing @pixeltherapy you have thought about this a lot :D

I think we need to define one of two things - are we

a) trying to convert a (or any) font file into svg
b) establishing a good work flow for these generated svgs to work with front end builds

Or in fact both - but for now it may be best just to concentrate on one.

I would personally quite like to look at b) (there already appear to be a number of tools for a) We can use font awesome as our example font, and Sara's article for the different ways in which you would use these generated svgs.

So bearing that in mind I do agree that having the whole Font Awesome repo is overkill and we probably don't need to fork it, but we do need to reference it so when it's updated svgs are generated (pref automatically), then we provide features that allow users to integrate the svgs via their choice. So generate a symbol file, a css file and a sprite sheet - these can be done vis gulp/grunt or node modules.

We can create a node build with gulp and grunt files in and the user can choose how they want to use the svgs.

So I guess if I was to answer the direction question - maybe b &c?

Also this repo seemed to have got a lot of stars - I'm wondering whether we rip it apart and put it back together right here...

[pixeltherapy]

I think so. You don't need much to get a general tool up and running so narrowing the focus makes sense. I'd like it to be easy to just swap out font-awesome assets for our compiled assets while providing the ability to create subsets within your build system should you wish.

Being a fork gives a lot of dross that we could do without. From the working prototype I put together, would you be happy to start afresh with that as the initial commit?

As far as I know there is no method to 'unfork' but apparently github can do it for you on request: http://stackoverflow.com/questions/29326767/unfork-a-github-fork-without-deleting.

Being the boss, might you drop them a line? :)

[Rumyra]

Contacted :)

Hopefully there won't be too much of a delay on that and we can strip this down 👍

[pixeltherapy]

Looking forward to getting this up and running :)

I had been ruminating on this idea for a while, and had tried out some of the tools, but hadn't yet decided to make use of it in production. When I saw the project mentioned on www.hotjs.net it just fit with what I was already kinda doing.

Where a tool like this would help me greatly right now, and what is a great use-case, is in WordPress theme development. The pain of having to refactor a whole set of templates, changing the markup to use SVG icons instead of icon fonts, is something that I've been reluctant to inflict on myself.

If this works well it would save me many a grey hair. My only concern is that browser support (Safari, this time, iirc) may be the limiting factor, but that's what we're here to hammer out.

[pixeltherapy]

@Rumyra Not a fork! :o)

I'm going to push this prototype to a feature branch to get started.

Edit: First things first... for a clean start, am I okay to make a destructive commit wiping all history, branches, tags and files from this repo?