Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving svg-sprite forwards #230

Open
jkphl opened this issue May 31, 2017 · 1 comment
Open

Moving svg-sprite forwards #230

jkphl opened this issue May 31, 2017 · 1 comment
Assignees
Labels
Milestone

Comments

@jkphl
Copy link
Owner

@jkphl jkphl commented May 31, 2017

This post was originally published on my website.

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 (#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 (#200)
  • Improved support for component library integration (#227)
  • Bring back the possibility of absolutely positioning and get rid of the random shifts in some browsers / situations (#142, #147, #162)
  • SVG gradient extraction into <defs> block during sprite compilation (#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 (#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

I'm very much looking forward to your input! :)

@hieunt88
Copy link

@hieunt88 hieunt88 commented Sep 5, 2017

I found myself relying on this great, well-documented library of yours more often than I realize. Thanks for all the great work. Keep it up!

For 2.x, I would love to see the "combining" mode in action.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.