A Complete Guide to SVG Fallbacks

There are some great tests from Modernizr that we can look at. Your best bet for inline SVG, extracted out into a function, is this:

function supportsSvg() {
  var div = document.createElement('div');
  div.innerHTML = '<svg/>';
  return (div.firstChild && div.firstChild.namespaceURI) == 'http://www.w3.org/2000/svg';
};

This tests if the HTML parser (which is what is used to parse content sent to innerHTML) can correctly generate an SVG element, basically by creating an element, injecting SVG, and testing the namespace.

As with <object>, a browser that doesn’t recognize <svg> will just ignore your SVG markup and treat its contents as HTML. But its not that simple. With <object>, browsers that do support the object will know to ignore the child content. With inline SVG, there’s no such built-in fallback. However, there are a few workarounds you can use.

You can include plain text inside your inline SVG code, and it will be ignored by any browser that supports SVG, because SVG text must be contained in a <text> element. You can even include hyperlinks within that text.

<svg viewBox="-20 -20 40 40">

  <!--Text Fallback-->
  I'm sorry, your browser does not support

  <circle fill="limegreen" r="19" />
  <path stroke="forestgreen" fill="none" stroke-width="6"
        d="M-12,3 L-3,10 11,-12" />
  <text dy="0.35em" text-anchor="middle" font-weight="bold"
        font-size="18px" font-family="sans-serif"
        fill="indigo">SVG</text>

  <!--Fallback with links-->
  Please upgrade to a <a href="http://browsehappy.com/?locale=en">modern browser</a>.

</svg>

Things to note:

• The SVG text (the word “SVG” in this demo) becomes part of the fallback text. We’ll talk about how to avoid this in a moment.
• The SVG <title> text does not become part of the fallback text. That’s because the no-SVG browsers interpret this as an invalid second HTML title element, and ignore it.

You cannot include any other HTML content within inline SVG: when the HTML parser in a modern browser reaches an HTML tag, it assumes that you forgot to close your <svg> tag, and closes it for you. Which means that (a) your SVG is corrupted and (b) your fallback text is visible in modern browsers. The only reason you can use links (<a> tags) is because they are valid tags in SVG, but don’t draw anything themselves.

Another approach here would be to start with HTML text, and swap it out with inline SVG should you detect with JavaScript it is supported. Imagine a “like” button in HTML:

<button aria-label="Like">
  <span class="inline-svg" data-xlink="#icon-heart">♥</span> Like
</button>

The span with the ♥ is the fallback there. The data attribute is what we’ll use for a fallback, in this case, a <svg>/<use> element.

if (supportsSvg()) { // see test above
  var inlineSvgs = document.querySelectorAll('span.inline-svg');

  for(i = 0; i < inlineSvgs.length; i++) {
    var span = inlineSvgs[i];
    var svgns = "http://www.w3.org/2000/svg";
    var xlinkns = "http://www.w3.org/1999/xlink";
    var svg = document.createElementNS(svgns, "svg");
    var use = document.createElementNS(svgns, "use");

    // Prepare the <use> element
    use.setAttributeNS(xlinkns, 'xlink:href', span.getAttribute('data-xlink') );

    // Append it
    svg.appendChild(use);

    // Prepare the SVG
    svg.setAttribute('class', "inline-svg");

    // Set a title if necessary.
    if (span.getAttribute('title')) {
      svg.setAttribute('title', span.getAttribute('title'));
    }

    // Inject the SVG
    span.parentNode.insertBefore(svg, span);

    // Remove fallback
    span.remove();
  }
}

You can use HTML text-formatting markup without ruining the SVG by including it within SVG <desc> (description) tags, which allow content from other namespaces.

<svg viewBox="-20 -20 40 40">

  <desc>
    <p class="warning">
        Fallback text.
    </p>
  </desc>

  <!-- ... SVG content ... -->

</svg>

Things to note:

• The main purpose of the <desc> tag is to provide alternative text description. Make sure the content of the tag makes sense to a screen reader.
• In order for <desc> to be recognized by accessibility technologies on all browsers, it should be at the top of the SVG, right after the <title>.
• You should also be able to use an SVG <metadata> tag to include all sorts of arbitrary markup without affecting the SVG or its alternative text. However, this doesn’t work in browsers tested (they insert implicit </svg> end tags).
• The SVG text content still gets included in the fallback text.

You could even include an <img> tag with a fallback image within the <desc> and it would display correctly in the old browsers without breaking your SVG in the new browsers. Don’t do this! Although modern browsers do not display the fallback image, they do download it, and we’re always trying to avoid double-downloads.

A possibility for an inline <svg> fallback is to set a background-image that is only used if the browser doesn’t support inline <svg>. So, using the test above, you give yourself a class to work with:

if (!supportsSvg()) {
  document.documentElemement.classList.add("no-svg");
  <em>// or even .className += " no-svg"; for deeper support</em>
}

Then say you’re using some inline SVG like this:

<button>
  <svg class="icon icon-key">
    <use xlink:href="#icon-key"></use>
  </svg>
  Sign In
</button>

You could use that new class to apply a background-image if needed:

html.no-svg .icon-key {
  background: url(fallback-key.png) no-repeat;
}

Demo:

You’ll have to create the PNG and size it yourself. There is a walkthrough article here on CSS-Tricks about using Grunticon to automate all this.

For the deepest possible support, you’d wrap the <svg> in a <div> and apply the background to that, so even if the browser totally rejects the SVG element, the fallback will still work on the known <div> element.

We covered this above in “the <image> trick” section for inline  fallbacks, but since this is really using inline SVG, let’s cover it in more detail here. To get an image fallback in SVG, without extra downloads, you need a way of including an image:

• That old browsers will recognize as valid HTML
• That the HTML 5 parser will allow inside <svg>
• That modern browsers will not interpret as an image to download.

As strange as it may seem, the SVG <image> element serves this purpose. The SVG <image> element is used to embed other image files within SVG. However, within HTML, every browser tested recognizes <image> as a non-standard synonym for <img>. In SVG, you specify the URL of the image file with the xlink:href attribute. In HTML, you specify it with the src attribute.

In most browsers, therefore, it is sufficient to include an <image> tag with a src attribute (pointing to your fallback image) inside your inline SVG: the old browsers will download the fallback, the new browsers won’t. Except for Internet Explorer, which downloads the fallback image even when it doesn’t display it. The solution is to put a null xlink:href attribute on the element. The IE developer tools still show it requesting the fallback, but it aborts almost immediately (<1ms in IE11 or IE10/IE9 emulation mode), before downloading anything. It looks like this:

<svg viewBox="-20 -20 40 40">
  <!-- SVG code snipped -->
  <image src="fallback.png" xlink:href="" />
</svg>

Now to address that one remaining fallback problem: the text from the SVG that gets dumped to the screen. It somewhat ruins our perfect fallback image replacement. We can use CSS to help us fix this, but it’s not straightforward. We can’t use a simple svg text { display: none; } because that would ruin the SVG graphic. You could use the detection JavaScript to set classes that will hide or display the text accordingly. But even then, you’ll be stymied by IE8’s non-standard approach to unrecognized tags: they are always treated as empty void tags with no child content. You’ll need to adapt the HTML5 Shiv code to include all the SVG tags if you want to be able to treat them as stylable containers.

A no-JavaScript option is to wrap all your SVG graphics code (except the fallback <image>) inside an <a> element. Without a hyperlink destination, an <a> element in SVG acts exactly like a <g> grouping element, so there is no harm to your SVG code. And because IE8 recognizes <a> as a valid container element, any styles applied to it will apply to all the text within it.

So the trick is then to apply styles that will hide an HTML link’s contents, but won’t have an effect on an SVG group. Absolute positioning and hidden overflow do the trick:

.hide-on-fallback {
  display: block;
  position: absolute;
  left: -100%;
  height: 0;
  width: 0;
  overflow: hidden;
}

SVG for Everybody is a JavaScript library for inline SVG fallbacks as well. It’s approach is to start with the most modern possible inline SVG: Inline SVG referenced via <use> pointing to symbols defined in an external file.

<svg role="img" title="CodePen">
  <use xlink:href="spritemap.svg#codepen"></use>
</svg>

If that’s supported, it does nothing. In the case of IE, it Ajax’s for the spritemap and injects it, making it work in modern IE where that normally doesn’t work. In the case of non-SVG supporting browsers, it helps you inject a PNG.

It’s only disadvantage is that the UA test it does isn’t very accurate. You’re probably better off Ajaxing for the SVG and injecting it all the time, which makes for good support and browser caching.