# XML Post-processing Steps ## No namespaces In an SVG tree all elements and attributes belong to the SVG namespace. ## No non-SVG elements and attributes Only SVG elements and attributes are preserved. And their names are stored as `enum`s and not strings. This increases performance and makes typos impossible. ## Only elements and text nodes XML can contain elements, text nodes, comments and processing instructions. Our tree contains only elements and text nodes inside the `text` element. ## Whitespaces trimming Not only text nodes can be present only inside the `text` element, but they are also trimmed according to the SVG rules, including `xml:space`. For example: ```xml Text ``` becomes ```xml Text ``` And ```xml Text Text ``` becomes ```xml Text Text ``` ## `style` attribute splitting The `style` attribute content will be converted into normal attributes. ```xml ``` will become ```xml ``` The produced SVG tree never has `style` attributes. ## CSS will be applied All _supported_ CSS rules will be applied. ```xml ``` will become ```xml ``` The produced SVG tree never has `style` elements and `class` attributes. ## `inherit` will be resolved SVG allows setting some attribute values to `inherit`, in which case the actual value should be taken from a parent element. Not only it applies only to some attributes. But some attributes also allow `inherit` only from the direct parent. `rosvgtree` handles this for us. ## Recursive links removal SVG supports referencing other elements via IRI and FuncIRI value types. IRI is `xlink:href="#id"` and FuncIRI is `url(#id)`. As in any link-based system this could lead to recursive references, which when handled incorrectly can crash your app. We're trying to detect all common cases, but it's not 100% guarantee that there will be no recursive links left, but we're pretty close. This includes simple cases like ```xml ``` and more complex one like ```xml ``` ## Remember all elements with an ID As mentioned above, SVG supports references. And it can reference any element in the document.
Instead of checking each element in the tree each time, which would be pretty slow, we have an ID<->Node HashMap to quickly retrieve a requested element. ## Links are groups The `` element in SVG is just a `` with a URL.
Since we really support only the static SVG subset, we can replace `` with ``. ## `tref` resolving [`tref`](https://www.w3.org/TR/SVG11/text.html#TRefElement) is a pretty weird SVG element. It's basically a way to reference text nodes. We resolve them automatically and replace them with `tspan`. ```xml Text ``` will become ```xml Text ``` ## `use` will be resolved This is probably the only breaking change to the SVG structure. The way the `use` works, is that it creates a shadow tree of nodes that it's referencing. This is a great way to save space, but it makes style properties resolving way harder. This is because when you want to get a parent element from inside the `use`, the tree should return `use`'s parent and not the referenced element parent. To illustrate: ```xml ``` If you simply call `node.parent().attribute("fill")` it will return `red`, not `green`. Because the current node is `rect1`. As you can imagine, this is pretty hard to handle using a typical DOM model. So instead we're simply coping referenced elements inside the `use` so it can be treated as a regular group. ```xml ``` will become ```xml ```
The main limitation of this approach, excluding the fact we're creating way more elements that we had initially, is that copied elements must not have an `id` attribute, otherwise we would end up with multiple duplicates.