By far the biggest advantage of SVG on the web is DOM integration, thanks to its choice of XML. This enables, among other things,
- Trivial adaptive styling: the simplest case would be matching color of surrounding text;
- Easy and relatively cheap dynamic updates to individual components, trivially integrated with any DOM-manipulation tech, including declarative frameworks big and small.
I don't see a binary format easily replicating those.
Edit: Of course it's okay to have more opaque binary formats.
SVG is firewalled off from js and css regardless of how you use it. The only way to practically interact with SVG content (i.e. make it actually more useful than a jpg) you need to embed it directly, which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer.
SVG is so bad people have been using fonts instead (which are binary).
And 99.9% of people who use SVG are doing it with illustrator or inkscape anyway, the binary vs text argument here seems totally irrelevant.
The only way to practically interact with SVG content [...] you need to embed it directly
Right, and this is actually pretty common -- you can use <svg> tags directly in JSX, and you can set up a build pipeline that lets you import .svg files directly into your .jsx/.tsx.
It's useful because you can do things like animate your SVG using CSS, driven from the JS/JSX code.
Most of the time (and speaking from experience here), any “interaction” with inlined SVGs happens at compile time, setting the size or colors. Animating opacity, scale is done via CSS on the container element.
And for complex animations you resort to Lottie. So interacting with SVG via its DOM API is incredibly rare.
No I don't agree. Simple things like styling the inside of the SVG or animating the colors is pretty common and does not require reaching for Lottie. I don't think Lottie is all that commonplace outside of very large codebases in borderline enterprise environments.
You're probably right in general, but I had a need just the other day to animate something other than opacity and scale. I realised I would need to inline the SVG to make it work, and it was pleasantly straightforward.
> SVG is firewalled off from js and css regardless of how you use it. The only way to practically interact with SVG content (i.e. make it actually more useful than a jpg) you need to embed it directly
You're contradicting yourself here.
> ... which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer
That doesn't make sense either. Removing the XML declaration and the doctype declaration can be done using the same editor you're using for your HTML at hand - unless you're referencing the SVG as external resource via href, and then you don't need to remove it all. XML and doctype declaration aren't needed for XML conformance anyway, and your tool should offer an option to export without these.
Note according to the WHATWG HTML spec (redacted snapshots of which used to be known as W3C HTML 5.x until recently) when used embedded in HTML, SVG content is actually parsed using HTML/generic SGML rather than XML rules. For example, unlike in XML, element/tag and attribute names can be written in any mix of lowercase/uppercase chars, etc.
I write SVG by hand every day, but I imagine to be the 0.1% you are talking about. The ability to write simple or complex graphics in text form both inside HTML or CSS is a feature, and an incredibly powerful one.
Hold up. Are you blaming SVG because you don't know the <object> tag exists? I mean, yeah, you're right that CSS won't come through with an <img> tag. It will with <object> though.
Ah, I misunderstood what you were trying to accomplish. Yes, it makes sense that you have to embed the SVG in your HTML doc. SVG isn't an image format; it's a document format just like HTML is. Embedding the SVG puts it in the same document context as the HTML and therefore the same styling context.
Would you expect a parent's CSS to affect HTML in an iframe, a separate document context? That would be confusing behavior to be sure. Side effects galore.
No I wouldn't, because a) iframes are used to provide isolation, and b) nobody really wants that.
The use case for styling external SVGs with CSS is waaay more obvious. We should at least have the option to do it, even if it isn't enabled by default.
Are you really going to compare a technology like SVG that was supported by IE9 (and lower with a plugin) with one only just supported by the Blink engine May, 2022 in Chrome 101?
For all intents and purposes with regard to web development, fonts have been monochromatic (except for emojis). Any with sufficient knowledge gathered over decades can write/edit an SVG in the editor of their choice, graphical or textual.
How does one edit their own color font? Can you do it in a text editor? Do most font editing programs support it? Or were you speaking of fonts purely as a consumer rather than a producer?
> SVG is firewalled off from js and css regardless of how you use it.
That's a weird claim, since most of my SVG customizations are done using CSS.
> SVG is so bad people have been using fonts instead (which are binary).
No they're not, SVG is far more popular than icon fonts, which has been in steady decline for years.
> And 99.9% of people who use SVG are doing it with illustrator or inkscape anyway
False again. SVG is a popular export format for myraid of desktop, mobile & online design & publishing tools and presentation software which I've used over the years, none of which were Illustrator or Inkscape. I've also hand edited lots of SVGs to customize it to look how I want, which isn't feasible for Icon fonts.
Are you sure you know enough about web development to make these claims?
All of my data viz code is React-controlled SVGs, for instance. I was able to implement generic zoom and pan on top of this. Also things like nested graphs look good in SVG
- Trivial adaptive styling: the simplest case would be matching color of surrounding text;
- Easy and relatively cheap dynamic updates to individual components, trivially integrated with any DOM-manipulation tech, including declarative frameworks big and small.
I don't see a binary format easily replicating those.
Edit: Of course it's okay to have more opaque binary formats.