More than that though, I work with large svgs and if there were dom nodes for all of the components, nothing would be able to render them :)
Sure, but this is just restating the problem so that the mental model fits the facts. However you rationalize it, you're forced to deal with the situation that you need your own parsing logic to work with SVGs. That's supposed to be the problem that the choice of XML solves.
Apart from that, the contents of the `d` element are describing individual components -- lines, curves, arcs -- which combine to compose one path. It's not necessarily the case that they need to be treated as one elemental shape, any more than the children of the <g> element are not considered to be indivisibly part of a whole, but rather as individually manipulable components which are organized by the <g> into groups/layers.
Why couldn't <path> be a similar principle of organization?
As I said in my other reply though, I'm just splitting hairs really.
As a user I think being able to specify the shape by just using the single d attribute is nice. Maybe because it invokes warm childhood memories of using turtle graphics back in the 80s :)
Once the components are parsed into whichever data structure is used internally (by the rendering library), wouldn't the memory and processing footprint be the same either way? I do agree, it would make the files much larger, but as pointed out in another comment, that should be a clear indication that XML simply isn't a good fit for this use case.
btw - I use SVG a fair amount myself, and have written my own path parser and builder recently. While it's not inherently too difficult, is definitely is annoying, especially when the format of the file (XML) should be able to accommodate the path components.
Semantically, if child nodes can be used for composition (e.g., a document element with child nodes that describe the document contents), then I don't see how any SVG <shape> should be different.
You could use a group full of individual paths, and call that a single shape, but it's not really a single shape. I know I'm just splitting hairs, but the DOM node thing is a bit of a problem for me.
PS I do think having two languages is a little bit silly really, but I don't mind that much
Yup. Each node comes with a significant amount of overhead. If every lineto command required a separate node, this map[1] would go from requiring a manageable ~3000 nodes to a laggy ~40000.
I ran into this while working on a population map[2]. To draw paths with variable stroke, I initially tried creating a path element for segments of different strokes. This was too slow to animate or even render without freezing the browser, so I ended drawing the path left to right then right to left, making the height offset smaller and larger to simulate a stroke.