Reputation: 3543
A design firm we are working with on a project has given us code and images for several mock pages with some curious features:
<img srcset="somefile.svg" src="somefile.png" />
wherever they reference images. Every svg file has the following content:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="1600" height="860" viewBox="0 0 1600 860">
<image width="1600" height="860" xlink:href="data:img/png;base64,iVB..."/>
</svg>
with the widths, heights and viewbox for that graphic.
The only reason I realized this was because I have to fix the mime type in that data url to be image/png
in order to get the images to display in each browser I am testing with.
Is there any reason for me to use these svg files at all? It appears that the srcset attribute here is being used to display the svg image in all supporting browsers and fall back to the png image in browsers that don't support the attribute. But the svg image is merely the png image with the added overhead of being in an svg file as a data url... Is there some browser bug or something that I should be aware of fixed by this contraption?
Upvotes: 2
Views: 1423
Reputation: 29511
Yes, in this case the PNG file is a fall-back for the SVG.
But as you note, there is nothing to fall back from, since the SVG contains nothing apart from a PNG Data URI which reproduces the external PNG file.
This looks like (elaborate!) contingency planning for a situation which never arose.
I think you can safely ditch the SVG files (and the srcset
attribute) and simply reference the external PNG files.
Upvotes: 2