4 ms·

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 specifi

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. What am I missing? This seems like a major area for improvement.

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 ago
  From 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 ago
    So then, "we'll just use XML except where it would be most useful"
    - ygra 12y ago
      It'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.
aidos 12y ago
I quite like it. And actually, if you think about it - they're semantically different. In one case you're dealing if a set of different elements, in another you have the definition of a single shape. 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 :)
- dperfect 12y ago
  > if there were dom nodes for all of the components, nothing would be able to render them 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.
  - aidos 12y ago
    I don't know the inner workings of it, but in web browsers the number of DOM nodes end up being the limiting factor when you're dealing with large SVGs. I guess because there are so many extra objects and everything needs to be tracked / event handling etc. If you were writing to a one way rendering to a surface I guess things would 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
    - 1wheel 12y ago
      > in web browsers the number of DOM nodes end up being the limiting factor 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. [1]http://bl.ocks.org/mbostock/5925375/ http://bl.ocks.org/mbostock/5925375/ [2]http://roadtolarissa.com/population-division/ http://roadtolarissa.com/population-division/

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 ago
From 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 ago
  So then, "we'll just use XML except where it would be most useful"
  - ygra 12y ago
    It'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.

aidos 12y ago

I quite like it. And actually, if you think about it - they're semantically different. In one case you're dealing if a set of different elements, in another you have the definition of a single shape. 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 :)

dperfect 12y ago
> if there were dom nodes for all of the components, nothing would be able to render them 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.
- aidos 12y ago
  I don't know the inner workings of it, but in web browsers the number of DOM nodes end up being the limiting factor when you're dealing with large SVGs. I guess because there are so many extra objects and everything needs to be tracked / event handling etc. If you were writing to a one way rendering to a surface I guess things would 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
  - 1wheel 12y ago
    > in web browsers the number of DOM nodes end up being the limiting factor 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. [1]http://bl.ocks.org/mbostock/5925375/ http://bl.ocks.org/mbostock/5925375/ [2]http://roadtolarissa.com/population-division/ http://roadtolarissa.com/population-division/