Moving svg-sprite forward
Gearing up for the second library generation
When I started developing svg-sprite more than 3 years ago, it was my first ever Node module and everything was totally new to me. I basically just wanted to create a JavaScript port of my iconizr project to get better integration into our build chain. Splitting out the SVG sprite creation part was just a logical step.
I would have never thought that it should become one of the most popular libraries for creating SVG sprites, with more than 100k downloads per month at the moment. I remember well the first issues on Github, like this one from that lovely Stefan Judis guy who I'm running events together with nowadays, or Shane Osbourne's suggestion to make it file I/O independent which basically paved the way for the Gulp wrapper I came up with later.
I'm extremely thankful for all the support, input and suggestions I got from the community over time. Unfortunately, I have not always been able to respond promptly or consider them for further development — sorry for that! It all just depends too much from my general workload, which is extreme at times. It saddens me that I haven't been able to find the necessary time for really improving the library for more than a year now.
At tollwerk we're still using svg-sprite on a daily basis, mostly as part of iconizr's Gulp wrapper, and we really wouldn't want to miss it. The necessity of having PNG fallbacks for SVG icons probably tends towards zero in the meantime and also we're longing for an alternative approach using inline SVGs for quite some time now. I happens that I might finally be able to take some time for tinkering around with the many ideas I have, so let me summarize most important ones and ask for your feedback and amendments. This is what I'm planning for the next generation of svg-sprite:
New features & improvements
- Single unified sprite format combining
<view>,<symbol>+<use>, suitable for both background, foreground and inline usage (jkphl/svg-sprite#81) - Plugin style architecture wherever possible — to allow for custom additions (transformations, templates etc.)
- Simplified configuration (mostly by combining and dropping features)
- Universal, all external JSON configuration for the CLI script so that it can be shared between all interfaces / wrappers
- Completely reworked padding / margin / boxing strategy — still looking for the the most intuitive way to scale / pad things (jkphl/svg-sprite#200)
- Improved support for component library integration (jkphl/svg-sprite#227)
- Bring back the possibility of absolutely positioning and get rid of the random shifts in some browsers / situations (jkphl/svg-sprite#142, jkphl/svg-sprite#147, jkphl/svg-sprite#162)
- SVG gradient extraction into
<defs>block during sprite compilation (jkphl/svg-sprite#74) - More intelligent handling of embedded CSS (consolidation of styles shared between shapes)
- Improved support for inline embedding & styling
- More accessibility features
- Possibility to create more than one sprite in parallel
Features to be dropped / deprecated
- Support for SVG stacks — I doubt anyone has ever used it, also it's mostly replaceable with the
<view>sprite style - The widely hated PhantomJS dependency — I guess it's benefits are rarely needed and I'd rather have this as an opt-in feature
Codebase improvements & refactoring
- Rewrite to ES6
- 100% test coverage
- Standardize code formatting / improve readability in the documentation (jkphl/svg-sprite#223)
Other
- Updated online configurator
- Better documentation, examples and best practices
- Possibly an accompanying JavaScript library for loading, dissecting and caching a sprite as well as swapping out references in HTML against inline SVG
This post was also published over at Github. I'm very much looking forward to your feedback & suggestions there!