snapsvg.io looks like a rather lovely client-side #svg library #bookmark via @hakimel

Yesterday we at Vísar tested the neat SVG image element hack on all the devices and browsers we had at hand to see how it performed and whether or not it was viable to use in production.

Given this markup:

<svg>
    <image xlink:href="http://example.com/the-image.svg" src="http://example.com/the-image.png" width="100" height="100" />
</svg>

Here’s a table of what each browser+device downloaded:

Note that the Kindle downloaded the PNG despite having pretty good SVG support. Tests carried out locally by watching the Django request logs.

At first, this looked perfect — browsers which supported SVG only downloaded the SVG (apart from IE 10), and other browsers just got the PNG. However, it seems that SVG image elements can’t be sized with percentages, meaning our flexible layouts were never going to work. I tried to fix it using the dreaded viewBox and user units (as I have previously to compensate for percentage-based units not being allowed in SVG paths), but that just led to everything being completely the wrong size.

So, (unless someone can show me how to fix this), whilst we think this is a great hack, it’s not going to work out for our product due to the weirdness of SVG sizing limitations.

MDN says FF has “implemented” the SVG text module, then goes on to list 13 presentation attributes which “don’t work”. How exactly does that count as implementing the module? Grr. This is why @supports is doomed.