It looks like this isn't some new, complicated iteration on SVG, but rather a big cleanup effort to make this more similar to existing HTML+CSS techniques, removing cruft from the "XML everywhere" era of the web. DTDs and xml:base are gone. The ability to specify geometric properties (like circle radius) is a big step up, so we can these properties using CSS the same way we would do it if it were a div in HTML. Improvements in text handling are a long time coming and will be appreciated.

Overall, I wouldn't be surprised if this makes implementation easier than SVG 1.1 rather than harder, improving the proliferation of vector graphics on the web.

Of course, you can still limit your images to SVG tiny if you want to.

With SVG you first have to parse the file into a DOM, because otherwise you can't really apply CSS (for which you of course also need a parser). On this way you avoid all the common XML pitfalls like xml entities blowing up your memory. If you want to show animated SVGs you need a javascript implementation, because half the browsers don't understand the animate-elements. Being able to include javascript probably is the reason why most image hosters don't host SVGs. Javascript in SVG opens doors to all kind of evil things like cross site scripting. So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most. Every program supporting SVG got this wrong at least once, and some like Inkscape still have a buggy parser. So you look up how to render this path and you see that you just have to render the border, but there are gazillions of options how to render borders you all have to support. So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text, but silly things like text whose baseline follows a path [1]. Because internationalisation is important SVG files of course can show different things depending on the locale [2]. So afterwards you just have to apply filters, which are basically half a pixel based image manipulation program [3].

I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset.

To proliferate vector graphics on the web we actually need a way simpler flat format. The only thing you actually really need is bezier paths and a way to fill them.

[1] http://www.w3.org/TR/SVG11/text.html#TextOnAPath [2] http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing [3] http://www.w3.org/TR/SVG11/filters.html

What it comes down to is that if you look at SVG as vector graphics for the web, it's quite complicated, but if you look at it as part of replacing Adobe Illustrator, it may not yet have enough features. Certainly, you can't represent a circle perfectly with a bezier curve.

Apparently "four cubic Bezier curves and gives an approximation whose maximum error is 0.0196% of the radius"

Machine-generated PostScript is challenging for me to read.

I wonder how efficiency of modern PostScript compares to SVG.

Several formats already exist for various use cases: PDF for printing, SVG for web graphics (simple content and icons), OpenType fonts for vector based text and SVG as an exchange format between vector graphics apps.

The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that.

PNG and JPEG files are also universally usable outside of browsers. Linux systems often use SVGs for icons, but that's basically where the support stops. If I want to include a SVG in a latex I have to convert it to postscript or pdf. If I want to include a SVG into a Word document I have to convert it into an emf (enhanced metafile). You can't use SVGs for cocoa, UIkit, WinForms or MFC applications out of the box. The reason probably is the complexity to support SVGs.

I disagree.

I regularly visit codrops and they show a lot of cases how you can use them. A lot of the frontend web development is using them a lot.

http://www.ns.nl/ the dutch train company, for example uses a mix of inline svg, background image svg and scr tags with svgs.

https://www.spotify.com/nl/ uses SVG in the logo, the account icon and the arrows.

https://www.digitalocean.com/ svg is best practise for having vector images on your site.

The nice thing of SVG is the compatibility with css, for the web it is a nice tool to use.

Google maps switched to SVG for street layers like ten years ago.

Such a vector-drawing ISA wouldn't be at all human-readable, but it'd be an excellent object-code format for other vector formats to compile down to.

To allow simpler implementation for both consumer and creator software. To achieve better performance (lower size, faster parsing and drawing).

> The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that.

SVG has some problems as a graphics format, which are highlighted in this thread. I'm not sure about PDF, I never saw it used as a vector image format, so can't judge much about it.

> On this way you avoid all the common XML pitfalls like xml entities blowing up your memory.

DTDs are gone, and with them, entity definitions. This particular attack is no longer possible in SVG 2.0.

> So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most.

The data strings—sure, their syntax could be more natural, yes. But it's certainly not difficult to parse a data string if you pay close attention to the spec. These specs aren't the kind of thing that random programmers should be implementing anyway, you'll want a proper SVG library to parse the SVG for you, and the SVG library will come with a test suite. This is no different than the way we parse JSON or HTML—we farm it out to libraries because it's easy to get it wrong.

But most text standards will produce a few broken implementations, SVG is no different. HTML parsers have disagreed since the beginning of time, there were recently some exploits for non-compliant URI parsers, and people have often forgotten the weird way you encode supplementary plane characters in JSON. Heck, if you look at "plain text" we can see a history of buggy programs, such as the NUL bytes that appeared in filenames for a buggy NFS server or the C0 AF directory traversal attack.

> So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text…

Multi-line text is a feature of SVG 2.0.

> I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset.

2.0 is not a superset.

Again, you may want to take a look at the linked article at the top. Check out the section titled "Removed". It includes non-trivial chunks of functionality like the DTD, which vastly simplifies the parser. SVG fonts are also removed, which is a big chunk of complexity.

Yes, if you're writing your own SVG parser, it can be a bit daunting, just like writing your own HTML parser. But removing the DTD and fonts is a win in terms of reduced complexity, and moving more attributes to styles reduce the complexity of making animations from the user's perspective.

For me, SVG will continue to be an essential part of the web. Maybe you won't use it for "images" per se, at least not the way you embed JPEG and PNG files into your web pages, but you'll still be using it if you use D3 or the other cool drawing libraries for HTML. Canvas isn't always the right tool for the job. Or, put it this way. SVG isn't just an alternative to PNG, it's an alternative to <canvas>.

> This particular attack is no longer possible in SVG 2.0.

You still need to configure your xml parser the correct way, this doesn't really change anything.

> But it's certainly not difficult to parse a data string if you pay close attention to the spec.

Or you just change the spec to follow the buggy behaviour when a few implementation have the same bug: https://lists.w3.org/Archives/Public/www-svg/2010Apr/0042.ht... which leads to new bugs https://bugs.launchpad.net/inkscape/+bug/1284409

I think the amount of issues you can find around svg paths with a bit of googling make a pretty good case that the format is overly complex.

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

At this rate, it'll become another html spec.

There are also plans to create SVG-in-OpenType fonts, which would embed SVG inside web fonts. I have very mixed feelings about that. It is nice to have fonts with multiple colors, gradients and animations. On the other hand, do I want to have the same compatibility problems with fonts as I already have with HTML/SVG? I'm almost hoping that SVG-in-OT fails and Microsoft's simpler multi-color font format wins.

This is pretty interesting where imgur has a http://imgur.com/r/gifs section but it's all mp4.

Imgur also introduced gifv—a faux extension—to easily identify video-enhanced gifs.

Of course, the internet is still full of glorious 256-color, chunky-sized traditional gifs.

It worked, but the performance was terrible for non-trivial documents. Anything over 10 MB started to get unstable and provide for a bad UX in the browser. There's no way to get any kind of incremental rendering, you have very little control over the rendering process in the browser once you've handed it off to SVG (terrible API), and there are all kinds of security restrictions that make lots of hacks necessary if you're loading SVG from some place like S3 (due to same origin policy, but there are some additional hoops to jump through unique to SVG as well). Especially bad was the inconsistency across browsers and different implementations. When something goes wrong in the SVG engine internals, you get cryptic error messages (no stack traces or indication of where to even begin -- most of the time the location of the error referenced in the SVG document is wrong as well, or just at the root element). Opaque "out of memory" errors, or the browser tab just crashes. It very much felt like dealing with a black box.

For non-trivial use cases, it makes it very hard to debug. The goal of using SVG was to standardize to a neutral vector format that we could use anywhere, client or server, and leverage a lot of the tools that can deal with SVG or can convert to/from SVG without having to write our own drawing "engine".

In the end it wasn't worth all the hassle and we ended up implementing our own drawing using canvas primitives. Too bad.

Our experience with SVG has been fantastic and we've found it very performant even on large workflows that are 20x screen area.

I should note that we are using React too with shouldComponentUpdate implemented to optimize DOM mutation.

Example at https://flowgear.me/s/hZfxYnf

In my case I wasn't even manipulating the actual SVG nodes, just using transform CSS operations on them (transform and transfrom3d).

I'm not convinced that using canvas would have saved me that much effort. You just don't know what's going to bite you until you start building with these things.

One of the nice things with svg is that I can work with it everywhere. In the browser, on the backend, I can even manually manipulate it in my text editor.

Fortunately I've opted to constrain myself to chrome. If I had to support all the browsers that would have been the thing that ate up all the time (irrespective of whether it was canvas or svg).

Anyway. Sounds like you've also experienced the complexities enough to understand that once you push things a bit harder than usual you need to do extra work to make things play nice :)

At the end of the day, I'm happy with the result. Besides, for all the trouble it's nowhere near as complex as other bits of our system!

I have been implementing links within svg using xlink:href:

<text xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="google.com">text</text>

Would this break the apps using xlink:href?