The fact that they are almost human-editable and can be inlined means we are bound to be disappointed when working with them in this manner
The fact that they are almost human-editable and can be inlined means we are bound to be disappointed when working with them in this manner
Here's an example: https://svkt.org/~simias/up/20210212-185105_svg.png
All the elements and paths are SVG generated from some javascript. You can interact with the various elements, move them around and the paths are updated in real time.
Of course you could do the same thing with a raster format by using a canvas and drawing a bitmap for instance, but SVG works at a higher level and lets you do these things a lot faster and probably with better performance. You can use CSS-styling, you can register javascript event callbacks etc...
Or to put it another way: if SVG was meant as an opaque machine-to-machine format, why even bother with the insane overhead of XML instead of using some dense binary format?
"The properties of the lines (color, opacity, fill...) can be used to programmatically add functionality..."
Fir example I recently made this 'hack' for gradient transform. even 'hacking' that was easier than maintaining and understanding complex canvas JS - at least to me.
[0] www.holysnacks.us
I do love the mix of css vars into SVG. it makes a lot of sense to me too.
However, for when you want that there is SNG¹. It can be a surprisingly fun way to perform minor corrections or filters to an image.
Then why bother with the XML? And why use the embedded DSLs in strings instead of the more verbose XML-way.