{"id":147254,"date":"2013-08-19T07:36:28","date_gmt":"2013-08-19T14:36:28","guid":{"rendered":"http:\/\/css-tricks.com\/?p=147254"},"modified":"2015-05-04T11:16:51","modified_gmt":"2015-05-04T18:16:51","slug":"svg-fallbacks","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/svg-fallbacks\/","title":{"rendered":"SVG Fallbacks"},"content":{"rendered":"
UPDATE<\/strong>: Here’s a more comprehensive guide to SVG fallbacks<\/a> we’ve published.<\/div>\n

There is a very clever technique<\/a> by Alexey Ten on providing an image fallback for SVG going around the internet recently. It does just what you want in the classic no-SVG-support browsers IE 8- and Android 2.3. If we dig a little deeper we find a some pretty interesting stuff including a bit of unexpected behavior that is a bit of a bummer.<\/p>\n

<\/p>\n

Alexey’s technique looks like this:<\/p>\n

<svg width=\"96\" height=\"96\">\r\n  <image xlink:href=\"svg.svg\" src=\"svg.png\" width=\"96\" height=\"96\" \/>\r\n<\/svg><\/code><\/pre>\n
The idea was based on Jake Archibald’s revisiting<\/a> of the fact that browsers render the <image><\/code> tag like <img><\/code>. It’s just a weird alias from the days of yore that can be exploited.<\/p>\n
What Displays<\/h3>\n
The technique is pretty close to perfect in terms of what supporting and non-supporting browsers display. IE 8, which doesn’t support SVG, it displays the fallback PNG. Android 2.3, same story. <\/p>\n
The part I got confused on was iOS 3 and 4. The native browser on those operating systems do support SVG, in the form of <img src=\"*.svg\"><\/code> or as a CSS background-image<\/code>. But with this technique, the PNG displays rather than the SVG. The trouble is that iOS 3 & 4 don’t support “inline” SVG<\/a> (e.g. using SVG with an <svg><\/code> tag right in the HTML) (support chart<\/a>). SVG support isn’t as simple as yes\/no. It depends on how it is used. <\/p>\n
The point: it’s weird to see <img><\/code> work and <image><\/code> not work in these cases. And since those browsers do support SVG, it’s a shame not to use it.<\/p>\n
What Downloads<\/h3>\n
Of course we also care about what gets downloaded because that affects page performance. Again it’s mostly good news. Modern browsers like Chrome only download the SVG. Android 2.3 only downloads the PNG. <\/p>\n
But we run into an issue with Internet Explorer versions 9, 10, and 11 (a preview at this time). In IE 9, you can see both images turn up in the Network timeline.<\/p>\n
<\/figure>\n
The PNG ends up with a result of “Aborted” and listed as 0 B received, but still affects the download timing. <\/p>\n
It is a similar story in IE 10, it just seems to abort quicker and move on to the SVG without much downtime.<\/p>\n
<\/figure>\n
Scott Jehl suggested<\/a> using Charles Proxy<\/a> to test what is being downloaded more accurately. Charles verifies that the PNG is being requested.<\/p>\n
<\/figure>\n
The size of the response body is indeed 0 B, so the abort happens fast enough that not much data is transferred. Although the request and response header combined is 782 B and it takes ~300 ms to happen. A Yoav Weiss points out<\/a>, the problem may be worse if there are blocking scripts at the top of the page.<\/p>\n
Also note there is some chance that using a proxy affects what is\/isn’t downloaded as Steve Souders points out<\/a> in this Jason Grigsby article<\/a> about Charles Proxy.<\/p>\n
Research by Andy Davies suggests that the PNG request isn’t aborted at all in IE 11 on Windows 7. <\/p>\n
\n
@stopsatgreen<\/a> @jaffathecake<\/a> @chriscoyier<\/a> In my IE11 \/ Win7 response isn't aborted and shows up in dev tools and pcap pic.twitter.com\/ypitwTYAAH<\/a><\/p>\n
— Andy Davies (@andydavies) August 19, 2013<\/a><\/p><\/blockquote>\n