If you ever need to interface with other tools that generate SVG you now need to have a way of essentially transpiling SVG from the wild into your tamed SVGs. Oftentimes this is done by hand, by a software developer and designer (sometimes the same person).

And this is for basic functionality that your designers expect and have trivial controls for in their vector editors, like "add a drop shadow."

The article goes into some issues with sanitization itself, and except for <script> these are a bunch of reasonable things that someone might expect to work or not have issues with. Sandboxing rendering isn't an unreasonable approach if you're not writing the parser and renderer yourself.

I'd love to see an agreed standard like OpenGL vs OpenGL ES for SVG. SVG-ES. Everyone agrees on the static, non-scripted elements that should work.

Look at what Microsoft did with Excel--the dangerous stuff is behind a switch.

Thus, solution:

Add two bits to the tag.

SVG1 does not execute any sort of script.

SVG2 does not follow links.

SVG3 is actually SVG1 + SVG2 as these are bit flags, not numbers.

Additional bits are reserved for future use if any other issues are found.

The only real safety is in the engine, not by any sanitizer.

Sanitization-wise it's already possible to strip scripting from SVGs and anything else you want, it's just that a library like DOMPurify to avoid ballooning in size doesn't include say a preset to handle the extra parsing necessary to make them behave like browsers treat IMG embeds, so it's up to devs to add their own.

But yeah, a world where a simple attribute to achieve the same effect as an IMG embed but for inlined SVGs would be nice.