Not a huge fan of this hot-take that pops up every once in a while. I love SVG and use it all the time, and think it's a fantastically designed language and sys

Not a huge fan of this hot-take that pops up every once in a while. I love SVG and use it all the time, and think it's a fantastically designed language and system. The places where it's lacking have nothing to do with bloat or verbosity. It's biggest short-comings are all fixed in SVG 1.2 (flowable text, stroke placement on path, etc), but it's just _still_ not implemented anywhere. And on top of that, some auto-layout options would be quite handy... or maybe some charting primitives. A few responses: 1. The spec is too long/complicated: Yeah that's cause graphics is inherently complicated. You can't simplify out the core of the thing you're trying to do. Sure "shapes" are simple, but anything that would be actually useful involves paths (interpolation modes), transforms, groups, blend modes, effects, gradients, masks, stamps, FONTS (don't get me started on fonts!) typography, and on and on. And that's just stationary 2d graphics! Add animations in there and it's a whole other deal. Strip it all out and yes, your spec is shorter. But then you need like 20 different file formats! One for each sub-domain. And good luck trying to make them all work with each other. The fact that it interoperates with CSS/JS _is a huge plus!_. You can have SVG without these things if you really wanted to, but the fact that they interplay with each other is a testament to good language design on everyone's part here. Also: The Postscript spec is 920 pages, and the PDF spec from 2008 is 750 pages. Graphics are hard! 2. SVG is verbose because it's XML: XML is pretty compact honestly, especially in SVGs. Consider: <rect width="200" height="100" x="10" y="10" /> vs. { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 } And that's me following best practices to have `"` around the values in the XML! It could be even more compact. It's only more verbose I guess when you have closing tags which in SVGs is mostly for the `<g>` element which is literally only one letter :P So... <g> <rect width="200" height="100" x="10" y="10" /> </g> vs { "type": "g", "children": [ { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 } ] } XML is really not significantly verbose for uses like this, and the auto-closing `/>` makes it even more compact. And at the end of the day even if it were more verbose, it's not sufficiently more verbose for me to super care. 3. Who is SVG for? It's for both humans and computers and strikes a compromise between the needs of the two. Computers: built in a hugely well-supported language like XML makes it super easy to parse/process computationally. If you wanted to build a renderer that supports just a subset of SVG, that would be a < 1 day task. The more you want to support, the more it would take. And it's human readable -- or at least as human readable as any textual representation of 2D graphics can be. And that's another piece of inherent complexity here: representing 2D graphics in (effectively 1D) text is _always_ going to be hard to "read", if by "read" we mean understand what it's supposed to be displaying. No text format will be able to get around that. TLDR: The flaws listed here with SVG are either mostly preference/minutia or complexity inherent to the problem-space itself (2D graphics in a 1D format) that aren't likely overcomeable. Don't get me wrong there are definitely flaws with SVG! But I don't think these are it.