Consider a status document of all SVG elements and attributes
Situation
Thanks for this wonderful project!
Let me give you a brief summary why I filed this issue. I plan to replace Inkscape with rsvg-convert (and as such librsvg) to have a more lightweight solution. However, Inkscape seem to favor a svg:flowRoot element when entering text. This is not always supported in different tools. When I've looked at librsvg, I wasn't sure what to expect (apart from testing all and everything, which is a time consuming task).
So this problem boils down to these interrelated topics:
- It's not clearly visible on the project site which overall versions and variants of SVG are supported (tiny, full, version 1.0, 1.1, 1.2?)
- The support status of elements and attributes are missing.
Proposal
I'm aware there is a Wiki page about SVG2 features. However, I see this not as a viable solution because of the following reasons:
-
It's incomplete.
It doesn't list all elements and attributes, gives just an overview. For example, my question above couldn't be solved with this document.
-
It's disconnected from the repo and their files.
If new features arrive (are added, changed, or fixed) the page can be easily forgotten.
-
Its content is not version controlled.
When cloning or packaging the project, it's not clear what features are supported in a specific version.
-
It's not possible to tag the Wiki page.
Sure, you can look into the history or copy the page, but it's difficult to pinpoint the content to a specific released version of librsvg.
Because of these issues, I'd like to suggest to consider a different approach. My idea would be:
-
Add a status text file to the repo.
Everybody can clearly see what's supported at a specific version.
-
Write the status text file in Markdown.
So it's nicely rendered on Gitlab.
-
Amend the README file to state which SVG version and variant(s) are supported.
If this is not feasible, reference to the status file.
-
State which elements and attributes are supported and which are not.
For an example, see what Batik[1] did. They provide a table.
-
Link from the Wiki page to the repo. If you prefer to keep the Wiki page.
With the above idea comes some benefits:
- It's one central source of information. Creating a pull request can lead to updating the support status. As such, leading to up-to-date information.
- The information is version controlled by Git.
- The status file can be rendered by Gitlab.
- Packaging would be easier
Hope this makes all sense.