4 ms·

> 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

> 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/

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/