SVGs generated from popular vector editing softwares can get very complex with cascading style overrides, transformations etc. Even though SVGz would reduce the file size, parsing the SVG tree and rendering will still be unoptimized.
Optimization tools do exist [1] to simplify the tree but they can do only so much good[0]. I think this format, built with optimality might be a solution.
[0]: Anecdotal. I once had to edit ~20 icons. The client had provided SVGs because they'd somehow lost the original AI files. When I imported them in Sketch 3, the nesting, masks, and transforms applied were absolutely horrifying! I had to optimize the icons using [1], which did remove the masks and transforms, but in the end I had to manually edit SVG's XML source to fix nestings. sigh.
I know exactly what you mean. Approximately everyone uses Inkscape in practice, but I too have had occasion to go into gvim and edit the Inkscape SVG by hand. I will say that it really helps to know what's going on, but having to is less than ideal.
("approximately everyone" to the point where Wikimedia occasionally considers just using Inkscape-as-a-service as the SVG renderer instead of rsvg, for best quirk-compatibility.)
Right!? I have another "fun" story, where I found using SVGs a bittersweet experience. The firm I was interning this summer had a third party project of extracting waveform data in PDFs generated from ECG machines. Since parsing PDFs are another horrible experience, I used Inkscape to generate SVGs, and then used XPaths to parse the SVG's XML to get the data. All was good except that the XML tree was ~30-40 nodes deep at places.
I do wish that XML based formats were more deterministic to generate. Order should matter, however, I have seen several tools generating something that looks like this:
It is impossible to use Inkscape without running through at least some of the tutorials. Once you have a good conceptual understanding and have found some of the stupid bits that make no sense (what, you expected "Object Properties ..." to contain, ooh I dunno, properties of the object?) it's entirely suited to doing proper work. But no, its interface is very bad on discoverability.
rsvg has had a bunch of annoying bugs and in general seems to be further behind in terms of sorted compliance and feature support. When I was creating SVGs for Wikimedia Commons I had to work around a number of rendering bugs. And I didn't even use Inkscape, I wrote SVG by hand.
In contrast, the lead developer of Inkscape is active both in code and on the SVG specification mailing list, oftentimes implementing new features ahead of time to see how well they fit into SVG and where the spec might still need to be changed.
In practice, when valuing spec compliance and feature support, Batik and Inkscape are the only sensible options. This has nothing to do with quirk compatibility.
Optimization tools do exist [1] to simplify the tree but they can do only so much good[0]. I think this format, built with optimality might be a solution.
[0]: Anecdotal. I once had to edit ~20 icons. The client had provided SVGs because they'd somehow lost the original AI files. When I imported them in Sketch 3, the nesting, masks, and transforms applied were absolutely horrifying! I had to optimize the icons using [1], which did remove the masks and transforms, but in the end I had to manually edit SVG's XML source to fix nestings. sigh.
[1]: https://github.com/svg/svgo