4 ms·
I was writing this exact reply. This has been bugging me forever. When reading SVG, you suddenly need to write two parsers. The only reason I can think of is
by nothrabannosir 12y ago
I was writing this exact reply. This has been bugging me forever.
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.
- tom9729 12y agoFrom the spec: "The syntax of path data is concise in order to allow for minimal file size and efficient downloads, since many SVG files will be dominated by their path data. " http://www.w3.org/TR/SVG11/paths.html http://www.w3.org/TR/SVG11/paths.html
- jessedhillon 12y agoSo then, "we'll just use XML except where it would be most useful"
- ygra 12y agoIt'd be a list, in a document format for tree-like structures. You cannot nest path commands, it doesn't really make that much sense to have individual elements for them. 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.