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

I like the "same number of elements as there were tags in the tree", but isn't that what we've got already? An SVG "g" tag is a separate tag in the XML file. If you remove the SVGGroupElement, won't the tree have fewer nodes than the source XML?

I'm in two minds about the "graphics groups dictionary": technically, any node can have an "id" attribute, and becomes an IMPLICIT graphics group (according to spec). In practice, the spec encourages EXPLICIT graphics groups:

"Grouping constructs .. provide information about document structure and semantics. ... as braille, and thus promote accessibility."

i.e. they are more than just some node-level tweak - they are important to the overall document.

In practice, looking at some huge (multiple megabytes of data) SVG documents, I'm finding that graphics groups are a life-saver. Without them, there's just too many named nodes (e.g. a world map has every single country with an "id" attribute. That's too many - literally hundreds - for navigating the doc. However, it typically ALSO has each continent as a "g" tag, which makes for a great "automatically provided" document index / nav structure).

A graphics group tells you, approximately:

"a human author decided that *this* set of nodes was important enough for you to give it it's own row in a human-visible document index / navbar"