reklis/SVGKit — comment on commit add8144bcdf7da5d6378358815db0247dbdf39c8
File:  line 0
By reklis:

I'm not sure how it would change things, I'll need to review the code first. I'm just thinking aloud. What you are saying makes sense.

On Dec 19, 2011, at 8:57 AM, adamgit wrote:

> How would that change things?
>
> AFAICS, they were always the same as other elements in the tree - I believe we have a 1-to-1 mapping to SVGGroupElement instances - but they were difficult / costly to extract. If you wanted to find out - at runtime - what was in the file, it was laborious.
>
> IME, a "g" element is a "higher than 1st class" citizen. At runtime, you rarely need to lookup elements other than g elements. In most (all?) SVG editors, the g element is used as the "user-created-group of objects" object. So, usually, you just want a list of "what g elements are there in this SVG?"
>
> On the flip side, it's poor practice to leave your g elements with no id attribute (when authoring an SVG file). e.g. I believe Inkscape now autmatically puts an id on every single g element as soon as there's more than one in a file, to make it easier to manipulate programmatically.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/reklis/SVGKit/commit/add8144bcdf7da5d6378358815db0247dbdf39c8#commitcomment-806135