The APIs of this project were designed around the SVGDocument, but the current SVG specification uses the concept of a SVG document fragment instead.
The current code assumes that every and each SVG image is a separate document with the svg element being the root element. However, modern documents often contain a number of SVG sub-trees (each being a different image) and the API of a SVG toolkit like this project should allow that.
Supporting more modern SVG should not be controversial, however this implies breaking backwards compatibility at the API level and some people may believe that this makes no sense for a project with old roots like this one. This issue is opened to discuss the change: If you have an opinion on whether the current API should be kept or not, please post it here.
The APIs of this project were designed around the
SVGDocument, but the current SVG specification uses the concept of a SVG document fragment instead.The current code assumes that every and each SVG image is a separate document with the
svgelement being the root element. However, modern documents often contain a number of SVG sub-trees (each being a different image) and the API of a SVG toolkit like this project should allow that.Supporting more modern SVG should not be controversial, however this implies breaking backwards compatibility at the API level and some people may believe that this makes no sense for a project with old roots like this one. This issue is opened to discuss the change: If you have an opinion on whether the current API should be kept or not, please post it here.