"SVG is a horribly complex format and an overkill for most projects"
Can this be given more substance..?
Does it also apply to SVG v1.1 (Tiny/Basic)? It seems to cover a similarity limited scope. From the landing page its unclear if its fundamentally doing something different. In my naiive perspective itd seem more sensible to just make a new way to encode SVG?
Just casually browsing the SVG spec[0] looks like it covers a lot of ground. Different coordinate systems, CSS styling, paths, clipping, filters, animations, scripting, fonts etc. There needs to be an open vector format that supports all of those things, but maybe it is inappropriate that this is what get shipped by default.
SVG Native was supposed to fix that [1]. SVG Native uses only one coordinate system, no CSS styling, no filters, no animation, no scripting and no text or fonts. However, it didn't get much interest and it's starting to look like a dead version of SVG.
Maybe there isn't any need for a simpler vector graphics format because no one is using TinyVG, either.
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..
Can this be given more substance..?
Does it also apply to SVG v1.1 (Tiny/Basic)? It seems to cover a similarity limited scope. From the landing page its unclear if its fundamentally doing something different. In my naiive perspective itd seem more sensible to just make a new way to encode SVG?