SVG: The Good, the Bad and the Ugly

SVG, short for “scalable vector graphics” is a format for, well, scalable vector graphics. In this article I summarize my opinion of the format, what its problems are and suggest what could be done to improve things.

SVG, short for “scalable vector graphics” is a format for, well, scalable vector graphics. In this article I summarize my opinion of the format, what its problems are and suggest what could be done to improve things.

I’ve been using SVG together with Inkscape regularly for a few years for sketches and graphics, and like to write it by hand to satisfy my love for precision and art through code. SVG and I have a kind of love-hate relationship. It’s powerful and has some nice free and open-source tooling, but the format itself is pretty ugly.

The Good

• It’s the format for vector graphics. It is well supported by a range of programs from Adobe Illustrator to Inkscape for editing and in various browsers.

• It’s a web standard so you can use it directly in websites. You can also use CSS with it.

• It’s XML-based, so the syntax is familiar, it’s extensible and can benefit from the vast XML ecosystem. For example, using XLink you can reference other elements and definitions in an SVG file. Or Inkscape uses custom XML tags to extend SVG into their editor exchange format.

• It’s powerful. You can do a lot with it. It obviously supports various path types and shapes, supports text and more, but also animations, gradients, effects and more.

The Bad

It’s a web standard. And as is customary for a web standard, SVG is magnificiently bloated. The SVG specification brings a whopping 826 (eight-hundred twenty-six) pages to the table. And as if that’s not enough, it’s also XML-based and cross-linked with other web standards, driving the scope of any implementation to dizzying heights.

If you want to be sure to correctly render all SVG files, not only do you have to consider 800 pages of SVG spec, but e.g. another 20 pages of XLink spec. Oh, and CSS as well, by the way. And, I shit you not, JAVASCRIPT. Yes. SVG files can include <script> tags.

SVG fits right in with web browsers. They’re hilariously bloated already, they already implement stuff like CSS and JavaScript that a complete SVG implementation requires. This problem of SVG is actually just the problem of the web in general. It’s scope is huge, it’s bloated and hard to work with.

SVG is nothing you could implement in a day. Or a week. Or a month. The huge amount of specifications, that are most often only partly implemented, makes it very hard to overview what supports what, confusing the user as to what features they can actually use if they want their SVG file to be universally supported.

Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically.

The Ugly

A central problem that can be extracted from the points listed above is the one I detailed in my article about language design for machines vs. humans: SVG doesn’t know what it wants to be, a machine-focused language or a human-focused language and ends up doing badly in both aspects.

Is it a machine-processible language? It’s far too bloated for that. Writing parsers, renderers and generators for SVGs is a huge task. The syntax is repetitive and complex. It has a lot of features that could be represented by more basic features.

But is it a format well-suited for direct usage by humans? Well, no. Firstly, the exhausting syntax and complexity is also bad for human users. Secondly, it misses a lot of features that would make it suitable for direct use. A graphics language that is meant for direct human use would be TikZ for LaTeX. While it’s not a great language regarding user experience in my opinion, it is definitely meant for humans and has the necessary features to help making creating complex graphics easy. But nobody would have the idea to use TikZ code as an interchange format for the finished graphic. Nobody would want to implement 1300 pages of TikZ manual just to view some graphic. Instead you compile it into an PDF (which is also a horrible format and badly bloated, but well). If SVG was a language meant for human use, compiling it into a machine-focused format would be the way to go as well, but as I said – it isn’t. It’s neither.

What now?

A good idea would be to develop a simple vector graphics exchange format that is desigend to be easily processed by machines. As minimal in features as possible. Maybe JSON-based, definitely not XML-based. You should be able to implement a basic renderer in a few days, or even better, hours, without depending on two metric tons of XML ecosystem libraries. Bezier curves, elliptic curves, fills, outlines and gradients should mostly suffice to represent every unanimated SVG. An extension could allow animations in a separate file extension.

This minimal and well-delimited format could then have a strict test suite and be implemented in browsers and image viewers with relative ease. Users could rely on their graphic working everywhere and implementers wouldn’t have to worry about implementing XLink, CSS and JavaScript as well. It could save bandwidth and computation power. Compilers from and to SVG could be written for compatibility.

It could be used as export format of user-facing programs like Inkscape or Adobe Illustrator. For people wanting to markup graphics through code there’s already stuff like TikZ, Haskell diagrams or Python matplotlib that could also export to the new minimal interchange format.

I’m actually thinking about making a slim machine-focused vector graphics format (the name “SlimSVG” has been suggested :D) and writing my own human-focused Haskell graphics creation library with similar goals for my own purposes in the future, maybe as a student research project for the university.

In summary: Decide whether a language is for humans or for machines and do one of those things. And do the one thing well instead of both, but badly.

Update 1: This article was posted on Hacker News and landed on the front page, currently it’s on rank 3. I’m honored! In the comments there somebody mentioned an interesting use of the <script> tag in SVG. I’m unsure though whether I should be impressed or horrified :D

Update 2: Somebody posted this on Reddit as well. Currently, there are over 150 comments, wow.

Update 3: PEOPLE, PLEASE. This is absolutely not about “XML is bad, let’s do JSON instead”. I actually like XML more than JSON in total, I’m a fan of XML schema and nice strong schemas. And while I still don’t like the syntax, XML generally is a good fit for a document markup language like HTML. I mostly wouldn’t care whether a good format with a good data model was encoded in JSON, XML, YAML, binary, Brainfuck or monkey feces. The encoding really is the least important part. I just think that for a strictly machine-focused format for data JSON would be a better choice.

I guess though I should have anticipated that saying that I don’t like XML and then mentioning the word “JSON” would start a religious war.