I have never understood why, when it comes to the <path> element, the entire definition of the path is shoved into one plain text attribute with its own specification language. Why couldn't there have been special nodes like <curve> <move> etc so that the path can be processed using standard DOM traversal? As it is, anyone using paths in a programmatic way will invariably end up writing error-prone parsing and composing logic to modify the `d` attribute.<p>What am I missing? This seems like a major area for improvement.
Am I missing some sort of mathematical simplicity in the elliptical arc specification, because it looks like an absolute mess; surely there must be some mechanism that allows you to specify an elliptical arc between two points using tangent definitions, bezier-style. As it is, there's a real mess there where rotating the end point around the start point, you have to rotate the elliptical axis in the opposite direction to maintain the same curve.<p>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.
I'm getting some real Baader-Meinhof here. I just started making SVG path animations at work and just checked them into mainline today.<p>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.