SVG Path Strings
roadtolarissa.com
roadtolarissa.com
What am I missing? This seems like a major area for improvement.
When reading SVG, you suddenly need to write two parsers.
The only reason I can think of is that the resulting file would end up too bloated.
But if that was really the reason, why did nobody say: wow, then maybe XML is not the right language for this? That would be the W3C admitting XML is not the right tool, but stubbornly sticking to it, anyway.
Unfathomable. There has to be another reason.
In any case, if it bothers you that much, writing an XSLT that takes path elements and transforms them into the path data syntax shouldn't be that hard.
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.
It looks like its one optimal scenario is in creating a rounded corner, which I guess is the common use case - but the unpredictability of how the curve changes if you move the end points without adjusting the corner radii seems to be a significant downside.
They were definitely considering the rounded corners use case; the details of drawing a rect element with a path[2] make arcs sound much easier to use than they actually are most of the time.
[1]http://www.w3.org/TR/SVG/implnote.html#ArcParameterizationAl...
I like the look of this tutorial, and I hope you make some more in-depth ones. Piling through W3C specs is no fun, and I could really use some good tutorials for when I need to get co-workers up to speed on SVG.