You should look at the resulting data in more detail. Seriously. At least do a couple of thought experiments, after familiarizing yourself with what an SVG representation actually looks like.
First, SVG is XML, which is fundamentally a text-based format. There are compressed representations, but support for them is not universal (nor universally required).
Second, a raster image is fundamentally a series of pixels with a color, possibly a different color in each pixel. So a simple alternating pixel pattern, like 0xFFFFFF 0xEEEEEE would have to be represented as a series of unit-length vectors that alternate between two colors. Any translation of the rasterized pattern back to a more vector-like representation requires some pretty clever de-rasterization heuristics.
Exercise #1: Take one line of 60 pixels alternating between two colors, and write out the SVG XML representation of it. Compare that to the PNG representation of the same 60 pixels (you are free to use any recognized PNG compression mechanism).
Next consider a rasterized linear gradient, at an angle of 30 degrees from the vertical. The color changes at every raster line, and also shifts horizontally from line to line. Again, how would you de-rasterize that back to a vector representation that specifies a gradient, angle, and colors?
Repeat the analysis on a radial (circular) gradient. You either have to encode a series of vectors, or de-rasterize back to the parameters for the radial gradient.
For your first scenario, I'd use patterns as described here:
http://www.w3.org/TR/SVG/pservers.html#Patterns
I don't understand your second example.
But I think you may have misunderstood what I was saying... I'm not saying we should de-rasterize existing graphics - we should just make SVGs a more widely supported format and use them extensively going forward.
As far as how to have a PNG fallback for browsers without SVG support:
http://www.w3.org/TR/SVG/backward.html
Last edited: