Embed whole SVG file instead of injecting specific icons

[jonathantneal]

Embed whole SVG file instead of injecting specific icons

[jonathantneal]

I like it a lot. I would add a few steps to fill in the blanks.

• Separate the path and hash from the <use> xlink:href attribute value.
• Update the xlink:href value with a prepended hash (combining the path and existing hash into a new hash).
• When fetching the SVG, update its elements with a prepended id (combing the svg path and its own hash).
• Additional combing might be necessary for internal hash references.

Note: I proposed something similar using <svg src=""> cite last year, but it ultimately had no momentum.

[fvsch]

One issue with embedding the whole SVG is that there might be some (or many) conflicts between ids in the document.

What if I have a <div id="profile"> in the page, and a <symbol id="profile"> in a sprite? Or if I have several sprite files (this is quickly becoming be a use case for big sites), and some use similar names, with the sprite file itself working as a namespace of sorts?

So this would have to be optional, imo.

[webbower]

@jonathantneal Agreed with your extra steps. We might want to make some of the steps that check for other sprite files optional. I'd wager most people using this will be only loading the one true SVG sprite file and so naming collisions would only be a potential if people used multiple sprite files, and even then, using more than one would mean they're likely using a 3rd party sprite file in which they'd hopefully prefix their identifiers.

@fvsch We could, at minimum, allow for a configurable prefix for the ids and xlink:hrefs in the SVG file (maybe defaulting to icon or svg). However, as the external SVG sprite linking (hopefully) becomes more mainstream, build tools like FontCustom that already allow for prefixing the icon identifiers during the build process.

Upon further mulling, I think this shim should be architected in a way that can be used with something like YepNope where you provide a public method that tests for browsers that don't support external linking and the configurable, main public method that runs the shim. There is still another SVG issue people may run into with IE8- supporting VML instead of SVG so a structure like that would allow people to use this shim and an SVG->VML shim that trigger as appropriate. The true test of success would be this library shimming the external linking issue and then another library converting the externally linked SVG->VML.

[shawnbot]

A couple of comments:

1. Having a standalone feature detection for external resource support would dramatically simplify this shim. I think that you can test for this by detecting the presence of onload in an SVG element, like so:

   'onload' in document.createElementNS('http://www.w3.org/1999/xhtml', 'svg')

2. VML support is a giant can of worms because it doesn't support some of SVG's core concepts, such as grouping or styling via CSS (not without using a behavior, anyway). I think raster fallbacks (or just even plain text substitutions) are the only sane way to handle vector graphics in IE8 or below.

[shawnbot]

Update: just checking for the presence of onload isn't enough, because it was first implemented in IE10, but no version of IE support external content (up through Edge 13). I'm looking at some asynchronous ways to test this.

[shawnbot]

Paging @jdalton: Did you have any luck with this approach?