Migrate to an API not centered on SVGDocument #40
Labels
enhancement
New feature or request
Comments
carlosame
added a commit
that referenced
this issue
Aug 17, 2023
If `KEY_SVG_SELECTOR` is set and the document is HTML, its value as a CSS selector is used to locate the element that will be used as the SVG root. In the case of the transcoding helper, if the selector argument is null then `KEY_SVG_SELECTOR` is used, and if also null then the previous behaviour follows. This new hint is part of the effort to make EchoSVG friendly to embedded SVG images. See also: #40
carlosame
added a commit
that referenced
this issue
Aug 18, 2023
If `KEY_SVG_SELECTOR` is set and the document is HTML, its value as a CSS selector is used to locate the element that will be used as the SVG root. In the case of the transcoding helper, if the selector argument is null then `KEY_SVG_SELECTOR` is used, and if also null then the previous behaviour follows. This new hint is part of the effort to make EchoSVG friendly to embedded SVG images. See also: #40
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: