[policy, no patch] Agree on a technique for loading SVG images in HTML that degrades to PNG

I have no experience with inline SVGs. Let's cast a wide net on our networks and try to solicit input from folks who have experience with such implementations.

We have a few issues that need to implement SVG images in HTML.

How should I understand that? You just can use an <img> tag and pass the path to the SVG file as source or you use data URIs and you are done.

Okay, so we could have to versions of files, one .svg and one .png file and with following code we could check whether SVG is supported and otherwise we replace the file extensions with png:

if (!Modernizr.svg) {
  $('img[src$=".svg"]').attr('src', function() {
    return $(this).attr('src').replace('.svg', '.png');
  });
}

This doesn't work if you svg is inline.

We could add a data- attribute with the src of the png file and replace all svg tags with img tags and src tag.

And of course, in the final script, no jquery involved and only a dependency on domready.

Are we using inline SVG or are we using image tags? Your solution sounds cool.

Where SVG is supported, browsers are almost always capable of inline SVG too (your main loser in this battle is Opera Mini).

http://caniuse.com/#feat=svg (basic)
http://caniuse.com/#feat=svg-html5 (inline)

When I use inline SVGs it's normally in a stylesheet and in most of my real-world experience we did this using Compass to inline the SVG into the stylesheet. This has the benefit of reducing HTTP requests because the payload for an unused SVG is normally pretty small. So you end up with something like this:

.my-selector {
  background-image: url('path/to/fallback.png');
}
.inlinesvg .my-selector {
  background-image: url('data:image/svg+xml;base64....');
}

Edit: this can be done by hand as well. There's absolutely no dependency on Compass for this technique.

You may want to look at http://grumpicon.com.

Helps to set up best practice code with PNG fallback. Not sure the exact technique used but some smart people I trust developed this. Plus it has an ASCII Unicorn, so it has that going for it.

#4 without jquery involved is ok with me.

So we have sth. like following code?

if (!Modernizr.svg) {
  var svgs = document.querySelectorAll('img[src$=".svg"]');
  
  for (var i = 0, j = svgs.length; i < j; i++) {
    var src = svgs[i].src.replace('.svg', '.png');
    svgs[i].setAttribute('src', src);
  }
}

I'd either use .getAttribute() and .setAttributes() but not mixing the two. Here I'd probably just go with .src in both cases.

Also if we're looking at performance I'd be better to do two loops, on where we read all src values and a second one where we change the attribute.

I just wanted do post an example how we could replace the SVG files. Forgot that we just can write to .src.

Is the technique already decided or are we waiting for more suggestions? I don't think that it is good to use libraries like Raphaël because we just could replace the SVG with a PNG, do you agree?

I asked Scott Jehl and Mat Marquis for their suggestions for markup (they developed the Grumpicon tool I mentioned above at Filament Group) for inline SVGs. Here's what they suggested:

<img src="foo.svg" onerror="this.src='foo.png'; this.onerror=null">

That seems pretty simple and straightforward.

yes but no. No inline js please, it's not the 90' anymore.

http://dbushell.com/2013/02/04/a-primer-to-front-end-svg-hacking/

One of my Twitter peeps ran a performance test on one loop vs. two loops. Looks to me like two loops is indeed the winner: http://jsperf.com/one-loop-to-rule-them-all

So I misread that graph. Higher ops per sec is better, so this appears to show that one loop would be better than two loops. Entirely possible I misunderstood how to set up these loops.

Made a update, the first test was not really relevant, a loop over 1 result is kinda not very useful. Also things were not reseted properly making the test inaccurate.

http://jsperf.com/one-loop-to-rule-them-all/2

Looks like two loops is generally the fastest option?

That library looks stunningly large compared to the code proposed by @nod_...? Are we missing something? Shall we contribute upstream?

I actually like both ideas that were proposed here — i.e., both the simple file extension swapping, but also the data- attribute approach for inlined/embedded data resources. Perhaps we should combine both into a single library?

FWIW, I ran http://jsperf.com/one-loop-to-rule-them-all/4 and the "non-src" approaches are significantly faster than the "src" variants in latest Firefox.

Have a look at Iconic. They have a script that converts <img> tags with a .svg srouce to inline SVG code. They also offer a PNG fallback option, though that is still being developed. I have been in contact with them, and they gave me a copy of iconic.js with .png fallback support enabled, and in my initial tests it worked perfectly, automatically switching to a .png source for IE8 and Android 2.3. I don't know how this would integrate with Drupal, but their system seems to be a good one.

There is also SVG Injector, which is open source and appears to be the basis for inconic.js.

The new picture element allows for image types on source elements. So that means you can provide an SVG as a source with type="svg" and have a png as a fallback. Since picture support is being implemented in browsers now, that means there will be actual browser support for this within the next few months. The revised version of Picturefill will have type support so this could work in older browsers too.

Entirely possible that the solution in the other issue might work well too. Just thought I'd mention this as Scott Jehl brought this up on Twitter the other day.

if(!abc.svg) {
var i=document.getElementsByTagName("img"),j,y;
for(j = i.length ; j-- ; ){
y = i[j].src
// If filenames ends with SVG
if( y.match(/svg$/) ){
i[j].src = y.slice(0,-3) + 'png'
}
}
}

I think this will help to u