I have been working on a Go/WASM canvas renderer for this subset, but the drawing overheads seem too high. I also tried rendering into WebGL, via creating an Image from a b64 encoded SVG. That works ok, until you try to manually (code, not CSS) animate any of the SVG attributes. Creating on the fly Images seems to leak memory (at least in FF) and trying to re-render into a texture seems to always involve a read-back. Overall not sure if I continue this route. Only Video seems to avoid the read-back, but are we supposed to render SVG into frames of video for efficient rendering? Of course I could inject into the DOM a 'naked' SVG, but it would be nice to find a route to use SVG via canvas or webgl. Maybe that would make the format more popular... But a binary format might be nice if rendering could be done via a shader :)

>SVG Native was supposed to fix that [1]. [...] However, it didn't get much interest and it's starting to look like a dead version of SVG.

It's pretty bad marketing to call a different product by the same name. Particularly when it chooses a totally different side of the trade-off versus its homonym. Not only have I never heard of SVG Native, I'm confident that I'm going to forget what it is in a few days because I don't have a proper name to remember it by. Also, the adjective "native" here gives me no useful information as to what problem it tries to solve — how do I infer "simplified" from "native"?

“SVG Native is a subset of SVG 1.1, which removes animation, interactivity, linking, remote resource loading, scripting, and CSS ”

So anyone who supports svg 1.1 supports this automatically. I guess it helpa define/narrow a small svg subset to target if you write a new renderer. For instance rendering with JavaFX primitives, this would maybe be achievable

And this new thing also sounds kinda like a subset of svg..