SVG: The Good, the Bad, and the Ugly (2021) | Hacker News Reader

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

eisfunke.com

85 pointsfanf259 comments

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...

IconVG was looking promising but it seems abandoned at this point... The README doesn't mention anything and the repo isn't archived, but the last real commit is from 3+ years ago

https://github.com/google/iconvg

There is also TinyVG [1]. See the previous discussion on HN [2].

[1] https://tinyvg.tech/

[2] https://news.ycombinator.com/item?id=35227635

And HVIF:

http://blog.leahhanson.us/post/recursecenter2016/haiku_icons...

https://news.ycombinator.com/item?id=40196333

That document has a really good summary of all the problems surrounding text rendering onto a canvas[1]. Having been through the pain of implementing such a system for my canvas library earlier this year I can sympathise with the decision not to include it in the proposed format's MVP.

What did disappoint me when reading the doc was the decision to place accessibility at the bottom of the list of priorities for the proposed format. There's a footnote that says "Accessibility being low on this list reflects that the needs can be met outside the format as well, and supporting them inside the format would be beneficial only to the extent that it provides greater flexibility to designers", but to me that seemed back-to-front: why not tell the engine/device that will display the image the (preferred) requirements for accessibly rendering (or describing) that image by including such data in the format, rather than hoping that the engine/device will make "best efforts" to support people with accessible needs in some unknowable way?

[1] Text section in doc - 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.

Something similar to the CBOR diagnostics format but formalized would be nice... since being able to tag semantics would make consistent interpretation of data content easier.

The problem with XML is that most tools around 2000-2010 used it for everything, including simple configuration files and even DSLs (the Maven v1 XML was a nightmare to maintain).

However, there are features of XML that are very useful for a document format like SVG. One of them is namespaces. For example, you can create an SVG and add custom metadata in another namespace, and then any viewer who uses a decent XML parser will show it without issues. That’s not possible with JSON, as there is no guarantee that an unknown key will pass. (although I prefer a simple format like JSON or TOML for config files)

XML is easier to edit by humans than JSON any-day. SVG is one of the few graphic markup languages whose basics one can pick up in a couple of hours and go to production. If folks object to XML, then they should also object to HTML, JSX, etc.

We just need browsers to implement SVG 2.0

IMO most of the problem with XML, and the reason why I hate using XML but find JSX and HTML perfectly fine, is that every XML document needs to start with some bullshit like:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

or:

    <?xml version="1.0" standalone="no"?>
    <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
        "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

It's not only verbose and extremely ugly but also impossible to remember.

That old doctype header has been deprecated for ~15 years. You can omit it and need not remember the same.

svg header is simply:

    <svg version="1.1" xmlns="http://www.w3.org/2000/svg">

Maybe read the manual once per decade ? Its like saying JS does not have support for lambdas.

I found them on a website listing the doctors for various XML-based file formats, I didn't realise it was out of date, sorry. Still, that doesn't change anything, my point stands. XML typically has horrible doctypes which are impossible to remember and ugly to look at or parse. I'm not critiquing SVG but XML after all.

Its one optional line in a header that you don't even need to use if you don't want to. But sure, lets throw out the baby with the bathwater. The fact that JSON cannot have comments is a far more serious drawback than a single line at the top of the document.

I like formats which are XML except without the <?xml?> and xmlns stuff. However, most XML I encounter does have that stuff, so it's a reason why I usually hate dealing with XML. This shouldn't be difficult to comprehend. You don't have to run defence for a file format like this.

This reads more like a case of you having left ambiguity in what exactly you disliked. And rather than defending the position, I found the reply fitting towards what it seemed like you disliked: the need for rather specific header tags. Now you've clarified it further, and it's clearer that it's not the need for header tags specifically that is the problem.

For what it's worth, I do agree that the syntax may be a tad strange. But I feel that, as with many of these issues, this is a tooling issue. Now, whether or not tooling will be made or not, for these kinds of problems, is unrelated.

As an aside, I rarely remember the HTML header tag; but that's fine, I have tooling that does it for me.

If you just use it in the browser, <svg> is all you need. The browser is smart enough to parse it as SVG based on the context (e.g. if it's embedded inside HTML, if it's linked from an <img>, or if it's served as Content-Type: image/svg+xml). And you can omit the version.

I honestly disagree that YAML is human editing friendly, the rules about where the indentations should go is not intuitive. Like when you have a key/value pair where the value is a list, are the dashes indented like this:

    array:
    - string one
    - string two

or like this:

    array:
      - string one
      - string two

I've found that the easiest way for me to edit YAML (when I have to, which is pretty much exclusively when dealing with CI stuff) is to write it in one of those YAML -> JSON converters online.

Either of the two examples you gave work.

Then that's a problem in itself: in an indentation based language where more indentation == more deeply nested, allowing multiple levels of indentation to correspond to the same level of nesting is really confusing.

The hype curve seem to have run its course and we should prepare for the backlash against JSON.

SVG often appears embedded in HTML so it makes sense to have it use similar angle-brackets syntax. Unless they also want to recast HTML in JSON (which I’m sure someone have proposed).

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

Thanks! Macroexpanded:

SVG: The Good, the Bad and the Ugly - https://news.ycombinator.com/item?id=26114863 - Feb 2021 (219 comments)

> 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.

It would be amazing if browsers just implemented all the features that were already specified in SVG2. Currently it seems like any new spec work on features that would be amazing for the web (e.g. SVG connectors) has been completely paused because browsers haven't even implemented what has already been spec'ed over a decade ago.

I found the <script> capability very useful for making interactive SVGs for CNC assembly diagrams for the Shapeoko 2.

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...

Usually when I have to use text in SVG I give up and use HTML in a <foreignObject> [1] tag. The article mentions that SVG is in an awkward halfway point between being useful for humans or a compile target for vector graphics. Text is where this becomes really obvious. Trying to generate SVG with <text> elements in it that end up where you want them is hopeless, especially if you don't know what font the text will be rendered in. I prefer specifying the x,y, width,height of a box that HTML goes into in a <foreignObject> tag and letting the browser reflow the text as necessary within that space. But that's still often not perfect, and I have run into browser incompatibilities when doing any more than basic CSS rules on the HTML inside.

[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/for...

I wanted to programmatically generate chord diagrams for ukulele in SVG. My solution was to make an SVG file in Inkscape that had everything in it that could possibly be in the diagram, and then marked it up for use with a template library.

Not very elegant, but it saved me time to work on the thing I actually wanted to work on. Not sure if this sort of approach would be applicable for your cut lists.

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'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

Well if you just do the generic version uncritically, you end up with all sorts of security vulnerabilities. Things like xml external entities, xinclude have causes quite a few security issues over the years when processing svgs.

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>

    {
        "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.

You're assuming the use of attributes for everything, though. The thing that irritated me immediately about XML is the arbitrariness of having both attributes and sub-elements.

Yep that can be confusing at times! Although I've found SVG to be pretty predictable with regards to this.

That's inherent in anything which represents a tree of nodes though. The nodes themselves have a set of attributes, and they have a list of children. JSON has the exact same "problem" if you choose to represent a tree of nodes as JSON with a "children" field which is an array of sub-nodes.

This isn't an issue if you use S expressions, simply because S expressions get rid of the concept of properties. But at that point, you end up with a rectangle with a sub-node called "width", which feels weird as well: the width of a rectangle is clearly a property of the rectangle, not a "child" of it? I'd argue that using S-expressions where each rect node must have x/y/width/height children is just a poor attempt at adding back properties to a syntax which doesn't natively support it.

Decent argument. But... I don't find making properties into sub-elements a problem. At least I didn't, until you brought it up. Ya bastage!

I love SVG as a consumer for flow chart graphics. Visio and Omnigraffle output to SVG and it displays nearly perfectly when pasted and rescaled in a powerpoint or embedded in HTML. The files are light compared to PNG and are guilt free git commit-able.

I even like XML as a user of my work’s external vendor’s configs. I edit subsections more than I write it. It is well documented, errors are easy to spot, and the file is git-able. I would honestly hate to see what that company would come up with in JSON or YAML configs so in this case XML is a great fit.

> And that's me following best practices to have `"` around the values in the XML!

Are you implying those are optional? They aren't. You can choose between " and ' but you need one of them. You might be confusing HTML rules with XML here? HTML is not XML. (That was XHTML, which failed…)

Good catch! Today I learned.

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.

Same actually! Here's an old project: https://rawgit.com/cdrini/wikidata-spiral/master/index.html?...

Do you have any of your old projects public to share? I love creative UI stuff!

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.

yeah, this doesn't really touch on the beef i have with SVG.

the problem I have is that SVG is complicated like the old web, but unlike the new web we also haven't created new standards like Flexbox and Grid that let you ignore the problems with the old ones.

For example, in HTML-land we have had z-index for a while to describe the order in which elements should render on top of each other. This doesn't exist in SVG, so the order of elements is the order that they are declared in markup, which can lead to very kludgy things.

In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc.

These are all things solved in SVG1.2, but of course the classic issue is that barely anyone has bothered implementing SVG1.2.

> In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc.

You can use <foreignElement> and just include HTML text with all CSS text layout capabilities to achieve that. It won't work in Illustrator or Figma, but it's fine for the web. I honestly am somewhat okay with that, let HTML+CSS handle what it's already best at instead of duplicating functionality into SVG.

The z-index is somewhat annoying for accessibility though, because the DOM order also determines the accessibility tree order, so it's not always possible to reorder the DOM to re-arrange the z-order without breaking screen reader order.

to be honest i think the warts of svg aren't necessarily the worst for writing svg by hand, though it's not great.

but it makes writing design programs that output svg, annoying. the need for a `textarea` element is so great it's already in what was supposed to be the next generation of the spec; and pretty much all SVG output software has a way to input text boxes to treat them like that. But I suspect the complexity of dealing with svg is why alternatives to the Adobe Suite have only become more numerous recently; it's a complex beast.

to me, .ai and .svg are the equivalents to .doc and .docx, but we don't really have a great alternative a la Markdown that is significantly easier to output.

> In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width.

Or to have a rectangle scale to the width of the text inside it.

I have been told by a member of the standardization committee that you are supposed to use Javascript for this kind of thing.

Do people really spend the time building specifications with no implementation in mind? I find that kind of fascinating. Like the people actually building the implementation aren't around yet to figure everything out, what works, what doesn't etc through the process of implementing; seems like a classic case of "works great in theory."

SVG has the added complication that there are two classes of implementer: browsers, but also the programs that produce it like Adobe and GIMP.

We are in a situation today where no one can realistically make a competing implementation for Chromium/Webkit/Firefox and at the same time only a company with a large amount of money can afford from and maintain those codebases. I think that's kind of a big problem.

Have you been following Ladybird browser project?

From an early (2022) post:

https://awesomekling.github.io/Ladybird-a-new-cross-platform...

> Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff.

> Sure you can. Don’t listen to armchair defeatists who never worked on a browser.

...fast-forward to this month:

https://awesomekling.substack.com/p/forking-ladybird-and-ste...

> Since then, SerenityOS has grown into a large OSS community with over one thousand contributors all over the world.

> Personally, for the past two years, I've been almost entirely focused on Ladybird

That doesn't really solve the problem. It will involve many many many many hours of development to get to the point where it's a viable alternative and if it ever does eventually reach that state, it will require lots of lots of hours of maintenance work.

Yes. The world's most powerful incredible capable hyper-media is challenging to rebuild. Thats not a bug: it bespeaks the beneficent featurefulness.

That's only fine if you just care about the Web as a software platform. What about security vulnerabilities? What about having choices in browsers? What happens when Google decides they are finally ready to deprecate manifest v2?

Largely it's an issue that no one sees redevelopment as a likely path to get rich. Cost wouldn't be outrageous. But in this age no one's building browsers and no one's building OSes because it's already a well served market. It's unclear why we would reimplement. Especially when there's perfectly good ways to completely redo the user experience while using the existing open source implementations!

Expecting to build a world class software platform for less than, oh, I don't know, maybe $25m invested in a good capable engineering team seems silly. What does the web take to redo? More? $100m? Maybe, but I expect significantly less.

Folks use this as such a scare tactic: oh, it's be so hard to do! There's some incidental complexity sure but it's not the bulk of the design, and most of the core & a huge amount of the capabilities are purposeful and solid in nature. Folks also try to work people up about performance: oh, it's so big and bulky. But there's plenty of data heavy very fast sites doing enormous things out there, for quite reasonable footprint, and we're only just getting into the webworker & wasm age where we can start using the existing platform much better. The web's stance continues to improve drastically, and that's not just by being harder to implement, it's by ever refining & improving. It's not gloom I see as we iterate: it's strengths adding together & reinforcing.

Last it just seems so hideously developer-centrix to imagine doing anything else. Nothing else has any legs to stand on for giving users agency. SVG, HTML, and CSS are completely unique in software development in that they leave the door open, are alive computing systems that users can modify & extend with the browsers and plugins that they want. There's no proposals remotely on the table anywhere to any degree that do 1/1000th as much for the user, to respect them & maintain their agency.

So, I don't think the web's scope is a problem. I think it's very doable to build your own world's best platform, for a pretty reasonable sum, if you can put together a small or medium business to do so. That's an ok bar. We can cobble together demoscene grade cool flashy things for less, sure, and that scratches a nerd itch. And maybe some of those will be good high and low level platforms both, be really good maybe even enduring particular ways of doing software. But will they be able to be adapted by users? But will they get it right & never change & never bloat themselves? But will perhaps they too need to evolve & change over time, allow for different styles? The Extensible Web Manifesto ideas have allowed the web to be an enduring low level platform across great architectural explorations & expressions, while still maintaining greatly similar base truths; that empowers developers to find & speak their own truths, while keeping an incredibly capable deepening hyper-multi-media lingua franca that right now the whole world speaks. The web is amazing and building a new browser is a bargain, especially given how excellent the ready-made test suites are.

But no, most engineers won't be able to diy one in their garage; that doesn't mean it's too big & it's ridiculous to insist on. Programming languages/llvm, kernels, none of these are simple or things folks could do de-novo, cheaply, with the needed breadth scope. The popular versions of all of these have had enormous effort poured in. But for some reason we've invented and applied a bar, saying sorry, the web and the web alone has to be doable as a hobby project. It's ridiculous to insist the platforms for the world should necessarily be primitive works. The web keeps winning precisely because it has generous platform for all.

Forking chromium or Firefox or using Webkit plus adding the missing components and fixing broken ones is also not cheap. Again, maintenance is expensive. That is after you find (or train) the people who can reason about those codebases.

Where the Web is heading, very soon it's end users won't be well served with Google being the only one willing and capable of footing the bill for it.

The Web is still a hack. The amount of effort required to present content in your intended layout is absurd, and still unreliable.

We need a re-do. A lean, clean SVG might be the ticket.

That just doesn't seem like a big problem, in fact.

It is a big problem when the only ones who can write browsers that will work on all the sites people care about are Big Tech.

Reply on news.ycombinator.com