Surely this can be solved by embedding the SVG in a data: URI?

neilk · on April 21, 2013

Or embedding it directly into the HTML - almost any browser that can show SVG can also handle it as markup.

But, the benefit of this technique (as far as I can tell) is decoupling, and any kind of embedding re-couples the data. Maybe in an acceptable way, if you can do it at a deploy step. It depends on what the use case is.

michaelbuckbee · on April 21, 2013

That would reduce the number of HTTP requests to one (but would also have the side effect of pulling in ALL of the different sized files)

mistercow · on April 22, 2013

Why? It's not including the images in the data URI, just the SVG. That should act identically to downloading the SVG as a separate file (minus the extra HTTP request), unless I'm unaware of some very dumb quirk.

estelleweyl · on April 22, 2013

including the data uri for the svg only makes sense. to include the data uri for all the images would be the same weight as downloading all the images plus about 10%.

The method at this link: http://estelle.github.io/clowncar/bgonly.html only does two http requests, the svg and the image used. We can bring that down to 1 by using data URI for the svg logic only.