SVG: The Good, the Bad, and the Ugly (2021)

I brought SVG to WebKit, back in 2005. So I guess I'm part of the problem.

I generally agree with the article, SVG is bloated and confused about what it's trying to do.

You're not alone in wanting something better. We had this same problem in Flutter. Ian Hickson (of HTML5 fame) made some attempts at seeing a better future you might be interested in: https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...

Not about SVG as such, but the XML nature of SVG.

I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, etc etc

I wonder if I will honestly, un-ironically, use XML in my next project for something where JSON could have done the job.

JSON is missing these small things make it very annoying (mainly comments, comma at end of last element not allowed, and the crappy ambiguities standard vs implementations about numbers, autoformatting of pretty printed JSON not standardized). Also not very readable as config format.

And YAML is human editing friendly but so horrible in other ways ( [US, GB, SE, DK, NO, ...])

I am sure there are lots of small competitors. But XML is already there, so well supported everywhere.

Previous discussion (2021): https://news.ycombinator.com/item?id=26114863

> Bezier curves, elliptic curves, fills, outlines and gradients should mostly suffice to represent every unanimated SVG

There are also filters, pattern fills, dashed strokes, etc. Also, mesh gradients (as supported by Inkscape) are immensely powerful but not yet standardized.

A lot of people are surprised to find <script> in SVGs and maybe that's a bad idea, but everything that someone thought was pure unnecessary bloat are actually features that users depend on. Maybe there is a cleaner and purer universal standard that covers everyone's use cases, but users already have SVG and would rather see incremental improvements here, as opposed to waiting for a new thing that is less capable.

Ooh, ooh, how about text is kind of a nightmare?

I ginned up some pretty inelegant stuff to rotate text 90 degrees[0] because I got tired of trying to figure out if there was a sane, blessed approach that I could generate with whatever Python library I was using.

Ditto right justifying text. I just ended up fudging it [1]. Like, this is a pretty basic functionality if you're mixing text into your graphics. And I'm pretty willing to go down a rabbit hole if I can find one. I realize that doing this requires knowing the size of the text as rendered or doing something funny like rendering LtR text RtL reversed (which wouldn't work for centered?), but this is something that seems reasonable to expect a straightforward solution to.

[0] https://github.com/longwalkwoodworking/cutlist/blob/a7c96028...

[1] https://github.com/longwalkwoodworking/cutlist/blob/a7c96028...

One other thing that is a bit weird about SVG is how some parts don't feel tightly integrated. For example, paths and SMIL events have their own syntax. And a lot of APIs related to them seem to be either abandoned, deprecated, or just hard to find. There's also SVG2 which is confusing, as it seems like no browser will ever implement it fully.

That being said, SVG allows you to create quite beautiful and complex effects with relatively little code.

There was a time that SVG was going to replace flash, or something like that, but these days people just use the "simple" subset. I've seen multiple implementations for the vector graphics based on compute shaders, impressive stuff, can render the tiger svg with no problem. Parsing the bezier curves out of the xml is not that hard compared to all the work needed the have this work on the GPU. Most people also don't understand XML, I'm building a sort of compiler for it with full support for Namespaces, Schema, XLinks and all of that, boring stuff that needs to be done, I don't understand why this needs to be your problem though and even then those standard are not THAT hard. You will only understand XML if you need to use XML. Yes XML is verbose but also your mom is fat and you still love her don't you? Developers look at me weird when I start talking XML, like I am some sort of boomer that want to limit women's right to choice or something like that. Better not to mention it, or I'll have to listen to them explaining why JSON is just better for hours on end without ever considering the strange bizz requirements I labour under.

I don't really have any complaints or accolades for the internals of SVG, but I was recently evaluating image format for use with a tile-based browser game and stumbled upon a performance issue.

After some quick experiments, I found that SVG is a total non starter compared to PNG and JPEG. At image counts in the tens, you can't tell the difference. If you are rendering a 20x30 grid of 600 images, SVG can take seconds, whereas the raster formats can redraw at monitor refresh rate.

My process now is to treat the SVGs as art source code and to raster them into various formats as required at design time.

I am a little bit disappointed by this outcome, as I was hoping for "infinite resolution" game art that would accommodate the varying zoom levels automagically. I will now be working with pre rastered tile sets for discrete zoom thresholds. I was expecting SVG to be slower, but not that much slower.

Not a huge fan of this hot-take that pops up every once in a while. I love SVG and use it all the time, and think it's a fantastically designed language and system. The places where it's lacking have nothing to do with bloat or verbosity. It's biggest short-comings are all fixed in SVG 1.2 (flowable text, stroke placement on path, etc), but it's just _still_ not implemented anywhere. And on top of that, some auto-layout options would be quite handy... or maybe some charting primitives.

A few responses:

1. The spec is too long/complicated: Yeah that's cause graphics is inherently complicated. You can't simplify out the core of the thing you're trying to do. Sure "shapes" are simple, but anything that would be actually useful involves paths (interpolation modes), transforms, groups, blend modes, effects, gradients, masks, stamps, FONTS (don't get me started on fonts!) typography, and on and on. And that's just stationary 2d graphics! Add animations in there and it's a whole other deal. Strip it all out and yes, your spec is shorter. But then you need like 20 different file formats! One for each sub-domain. And good luck trying to make them all work with each other.

The fact that it interoperates with CSS/JS _is a huge plus!_. You can have SVG without these things if you really wanted to, but the fact that they interplay with each other is a testament to good language design on everyone's part here.

Also: The Postscript spec is 920 pages, and the PDF spec from 2008 is 750 pages. Graphics are hard!

2. SVG is verbose because it's XML: XML is pretty compact honestly, especially in SVGs.

Consider:

    <rect width="200" height="100" x="10" y="10" />

vs.

    { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 }

And that's me following best practices to have `"` around the values in the XML! It could be even more compact. It's only more verbose I guess when you have closing tags which in SVGs is mostly for the `<g>` element which is literally only one letter :P

So...

    <g>
        <rect width="200" height="100" x="10" y="10" />
    </g>

vs

    {
        "type": "g",
        "children": [
            { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 }
        ]
    }

XML is really not significantly verbose for uses like this, and the auto-closing `/>` makes it even more compact. And at the end of the day even if it were more verbose, it's not sufficiently more verbose for me to super care.

3. Who is SVG for?

It's for both humans and computers and strikes a compromise between the needs of the two. Computers: built in a hugely well-supported language like XML makes it super easy to parse/process computationally. If you wanted to build a renderer that supports just a subset of SVG, that would be a < 1 day task. The more you want to support, the more it would take.

And it's human readable -- or at least as human readable as any textual representation of 2D graphics can be. And that's another piece of inherent complexity here: representing 2D graphics in (effectively 1D) text is _always_ going to be hard to "read", if by "read" we mean understand what it's supposed to be displaying. No text format will be able to get around that.

TLDR: The flaws listed here with SVG are either mostly preference/minutia or complexity inherent to the problem-space itself (2D graphics in a 1D format) that aren't likely overcomeable. Don't get me wrong there are definitely flaws with SVG! But I don't think these are it.

Years back, I had the most fun I've had with creative UI when creating really expansive svgs and animating path with css. I will likely never do it again, but it was a great intro into splashy web development.

With great powers come a lot of people very mad about how we miuse them & that we might not be able to reimplement it all in a weekend.

> 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

That just doesn't seem like a big problem, in fact. The webs gotten pretty good & the standard is pretty high. Yes people have some real pains but also my word, software is a world of contrived griefs, nonsense beefs. People love grandstanding against things.