We’ve recently launched our new Learn Page. In case you haven’t noticed, please see it in detail here.

This redesign was long overdue and we’ve collected many tips and ideas from our community over the past few months. The goals of the new layout were the following:

• Provide a clearer order and grouping of content, divided between individual languages and goal-driven paths (Web Projects and APIs for now).
• Suggest a clear starting point for newcomers (Web Fundamentals) placed at the very top of the page.
• Deliver an indication of progress on all initiated tracks. Notice how the “Explore” button changes into a “Continue” button with corresponding completion percentage on all ongoing courses.
• Offer a redesign more in line with our brand and existing color scheme.

We hope you like it, and as always please let us know if you have any thoughts or suggestions.

There is a very clever technique 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.

Alexey's technique looks like this:

<svg width="96" height="96">
      <image xlink:href="svg.svg" src="svg.png" width="96" height="96" />
    </svg>

The idea was based on Jake Archibald's revisiting of the fact that browsers render the <image> tag like <img>. It's just a weird alias from the days of yore that can be exploited.

What Displays

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.

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"> or as a CSS background-image. But with this technique, the PNG displays rather than the SVG. The trouble is that iOS 3 & 4 don't support "inline" SVG (e.g. using SVG with an <svg> tag right in the HTML) (support chart). SVG support isn't as simple as yes/no. It depends on how it is used.

The point: it's weird to see <img> work and <image> not work in these cases. And since those browsers do support SVG, it's a shame not to use it.

What Downloads

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.

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.

The PNG ends up with a result of "Aborted" and listed as 0 B received, but still affects the download timing.

It is a similar story in IE 10, it just seems to abort quicker and move on to the SVG without much downtime.

Scott Jehl suggested using Charles Proxy to test what is being downloaded more accurately. Charles verifies that the PNG is being requested.

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, the problem may be worse if there are blocking scripts at the top of the page.

Also note there is some chance that using a proxy affects what is/isn't downloaded as Steve Souders points out in this Jason Grigsby article about Charles Proxy.

Research by Andy Davies suggests that the PNG request isn't aborted at all in IE 11 on Windows 7.

@stopsatgreen @jaffathecake @chriscoyier In my IE11 / Win7 response isn't aborted and shows up in dev tools and pcap pic.twitter.com/ypitwTYAAH

— Andy Davies (@andydavies) August 19, 2013

Findings

I did the display tests from this Pen, but the download tests I made sure to do with just one of the techniques present on the page and using Debug View so there was nothing else on the page but the raw technique.

See the Pen SVG Tests by Chris Coyier (@chriscoyier) on CodePen

So, Fallbacks

The Alexey Ten is still clever and if the iOS display issue and IE download issue is acceptable to you, it's still usable. Here's some more fallback techniques, which differ depending on how you use SVG.

If you're using SVG as a background-image...

Modernizr has an SVG test. So you could declare a fallback with the class names it injects onto the HTML element.

.my-element {
      background-image: url(image.svg);
    }
    .no-svg .my-element {
      background-image: url(image.png);
    }

That shouldn't have any double-download issues.

An even better technique (because it doesn't require a dependency) is to use a little CSS trick with multiple backgrounds:

.my-element {
      background-image: url(fallback.png);
      background-image: url(image.svg), none;
    }

This works because it just so happens that the browser support for SVG and multiple-backgrounds is very similar. If multiple backgrounds is supported, the browser will use the second declaration (with SVG), otherwise fall back to the first declaration (with PNG).

If you're using SVG as <svg>...

That means you're probably already OK with the slightly-lower support for inline SVG. Meaning the <image> technique might be OK for you:

<svg width="96" height="96">
      <image xlink:href="svg.svg" src="svg.png" width="96" height="96"/>
    </svg>

David Ensinger posted a technique using the <foreignObject> tag in <svg>. But the trouble with that is the fallback is loaded no matter what resulting in the double download all the time instead of just sometimes like the <image> technique.

You could do something like:

<svg> ... inline SVG stuff ... </svg>
    <div class="my-svg-alternate"></div>

Then use the Modernizr SVG test again to get the support HTML class and then...

.my-svg-alternate {
      display: none;
    }
    .no-svg .my-svg-alternate {
      display: block;
      width: 100px;
      height: 100px;
      background-image: url(image.png);
    }

If you're using SVG as <object>...

You could use the object tag itself as the element to style after the Modernizr test.

<object type="image/svg+xml" data="image.svg" class="logo"></object>

.no-svg .logo {
      display: block;
      width: 100px;
      height: 100px;
      background-image: url(image.png);
    }

If you're using SVG as <img>...

Scott Jehl prefers:

<img src="image.svg" onerror="this.src=image.png">

That requires HTML though, so if that's not possible or practical for you, you could swap sources with Modernizr. This uses the JS API of Modernizr, not the class names:

if (!Modernizr.svg) {
      $("img[src$='.svg']")
        .attr("src", fallback);
    }

Where fallback is a string of a URL where the non-SVG image fallback is. You could keep it in a data-fallback, use a consistent URL pattern where it just replaces .svg with .png, or whatever other smart thing you can think of.

SVGeezy is a library just for this.

Or you could use a similar technique as with the inline SVG and object techniques where a hidden DIV is displayed with a fallback.

Alrighty Then

If this post didn't mean much to you because you aren't using SVG yet, you should because it's awesome. This post could help you get started.

If you have more data to share, we'd love to hear.

Good luck!

SVG Fallbacks is a post from CSS-Tricks