Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Inline vs External SVG #1
This is what I think is the best way...
1. Folder full of SVG icons as the base.
2. A build step of some kind to smoosh them into a file
This same build process should probably build PNG versions as well. Like
3. Test for inline SVG support.
4. Logic for support or non-support
Probably put this in the
5. If supported, Ajax...
Grab the file and drop it in body. The point of this is that it's browser cached. But... that depends on proper headers, can you count on that in WordPress land?
Alternative is to PHP include the
6. If NOT supported, fallback...
There are a variety of fallback methods...
Alternative to that whole setup...
Just use Grunticon wholesale. It would be simpler, it's just not my favorite because it locks you into that setup forever. You're using a meaningless
It's probably best to define some more goals for this project. Like clearly defined browser support requirements, build tool possibilities, whether you need to support no-js or not, etc.
Our browser support etc are determined by WP core. Pulled from our autoprefixer settings, we say we support Chrome 21+, Firefox 17+, IE7+, Opera 12.1+, Safari 6.0+, Android 2.1+ – But for the older browsers, like IE7, I know we can get away with "not broken".
I think we've had the no-js conversation for fallbacks before, I'll see if I can look that up.
The issue with SVGInjector is that the markup you use is:
Which means that the prefetcher will trigger HTTP requests for each of those images individually. 20 icons on the page, 20 HTTP requests. It's kinda nice when building an icon system to get that down to 1.
First of SVGInjector is cacheable
This is one of the examples that they also show on the page
So it does not make a subsequent request if that's what you are referring to?
However, there are some kickbacks from using a SVG spritesheet.
That looks better for sure. It kinda seems like it doesn't address spriting though (like making sure only 1 request is made for all icons). Maybe that's not a big deal for WordPress? I dunno. It's always a big deal to me, but your icon system I think needs to be author-extendable, so maybe it's better if it's not sprited. There are kind of a lot of icons on any given WP admin page though, plus the current icon font system is essentially a one-request sprite, so probably best to be at least that performant.
This is actually already possible (but apparently is a little janky?): http://mannieschumpert.com/blog/using-wordpress-3-8-icons-custom-post-types-admin-menu/
Right now plugin authors can add their own svgs, set of pngs, or an icon from the Dashicons font.