I can’t say I have a personal favourite because I don’t do a lot of production work — my main target audience is usually people learning SVG!

More generally, however, I think it really depends on what you’re trying to communicate. I don’t think you need an identical image on every browser, but you do need to get the message across and to make sure your site is still functional (as much as possible).

So, a basic alt text is often going to be enough for icons. For complex data viz, providing a text/table version of the data is something I’d recommend for many reasons, but it isn’t going to convey all the information of a well-designed chart. I tend to lean to the no-JS solutions as much as possible, so the <image> trick would be my next go-to. And probably I would now use Tigt’s approach to hiding the extra text.

I was set to use the <image> trick, but now I’ll be looking into Tigt’s Pen, as I want a no-JavaScript solution.

The only thing I was hoping to see is what method you personally favor. (It seems Chris “goes commando” with no fallback.)

So far I’ve opted for <object> using inline base64 data uri of the svg and inside a <div> that has a class to load the PNG fallback. The CSS for that is set in an inline <style> in the head.

I’ve added wrapping <div> with role=”img” and aria-label for accessibility.

Yes, a server-side sniff test is always another option, no matter how much it is frowned upon.

I would like to think that it is highly unlikely that any new browsers will come on the scene that don’t support SVG, so the above code is probably not going to bite you.

Ah, yes, that’s a nasty caveat with <title> and <desc> — they need to come first, before any child content. It was a performance issue at the time the spec was written; browsers didn’t want to have to search for these elements. I suspect the performance issues are less relevant now, but even if we remove that requirement from SVG 2, you’ll still need it for backwards compatibility.

I’ll correct the example to use that structure.

That was supposed to be:

if (!Modernizr.inlinesvg) {
  $('#containing-div').prepend(img tag with its source set to fallback.png);
}

if (!Modernizr.inlinesvg) {
$(‘#containing-div’).prepend(”);
}

As long as I’ve removed the xmlns link in the SVG, IE8 just ignores the SVG block without screwing up the page, and loads the .png fallback.

Yeah, I see those references, and I guess I am just being nit picky. :D

I personally love to feel reassured that there are ways to avoid fallbacks if you have or can establish some sort of control over what browsers will view the site/app. Thanks again for the article!

I apologize Amelia. Thank you Ma’am!

Another concern would be for users with images turned off (or, somehow, just SVG turned off) and making sure your site is still usable without the image. This is definitely a larger concern that should be addressed on a holistic level (and not just concerning images,) but these techniques may help in that area.

If you
– don’t mind detecting “Browsers” instead of “features”
– Are using SVGs in tags

Then one very simple way is to use an .htaccess (or whatever floats your web) to redirect old browsers to the png version of your svg.

RewriteCond %{HTTP_USER_AGENT} "Android 1" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "Android 2" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "Android 3" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "MSIE [6-8]"
RewriteRule ^(.*).(svg)$ /$1.png [L]

Double-checking the spec, it may be possible that screen-readers don’t announce <desc> elements that aren’t at the top of their parent element. I guess I’d have to test it!

Yeah, the only compatibility info I could find was on MDN, but it seems pretty safe from there.

Can you explain the “being hostile to screen readers”? Were you having problems when using simple marked-up text (like in the example), or were you trying to embed complex content such as images?