SVG 2 new features
github.com
github.com
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
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.
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.
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.
I also prefer to work in SVG directly, i.e. not with some export from an Adobe product. Inkscape is helpful at times but normally it is much easier to do one's own primitives than to have some path that does a circle in however many points. It is great when you can do something like an Instagram icon in four lines of SVG (including colour gradients) than the 1.4Mb EPS file provided in their brand resources.
I do scour the web for things in SVG that are to my personal standards of doing it, i.e. cruft free with a sensible viewbox etc. Yet rarely do I find anything that is that good. It is like the difference between HTML and MS Word documents exported to HTML, with proprietary tags etc.
I do not work too well with the graphics team I work with when it comes to SVG - they are still in the print era and not on the same page as me. They are no more able to work with SVG than the Office Manager is able to make the leap from MS Word to editing HTML in 'vi'.
Regarding usability, for 'supported browsers' (no IE 9-) SVG is great. A year ago I would not have thought that.
For us programmer types SVG is accessible, for graphics guys it isn't really. This I like as I can work with my frontend developer on SVG and not really need 'assets' from the graphics guys still stuck with GUI desktop publishing software that should have been left in the 90's where it belongs.
Want the logo a bit smaller? Want that little design element bigger? It's incredibly convenient knowing you can change up your design a bit without having to regenerate your graphics.
JPEG files were the standard for photographs before the first browser was written.
PNGs are super easy to support if you don't care about gamma correction, so it's no surprise that they're widely used.
Vector formats are another beast altogether. Notice from your example that you can't include the EMF in latex either, since an EMF is basically a set of windows draw commands. I'm not sure about the current status of Postscript in Word. Years ago you could embed EPS files but they wouldn't display and only print if you had a postscript printer.
Vector formats are just difficult.
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.
Machine-generated PostScript is challenging for me to read.
I wonder how efficiency of modern PostScript compares to SVG.
> 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.
Even on the web wikipedia prerenders als svgs to have uniform look of them on all browsers, image hosters don't support them (probably because they could contain javascript), when I see something that looks like a vector graphic on the web it's >90% of the time a png.
[1] http://www.w3.org/TR/SVG2/styling.html#RequiredCSSFeatures
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"
The worst thing about this is, there was (and still is) one. It was invented by Macromedia 20 years ago and featured scalable vector graphics and animation in an extremely compact, easy-to-render format that worked great on the computers of the time. Later versions added interactivity and Turing-completeness, then Adobe bought them and it turned into a bit of a mess with all the security problems.
I'm talking about Flash (SWF). If you ignore all the interactivity and Turing-complete features added to later versions, it is at its core an efficient and relatively simple vector graphics format. Because it's a binary format, parsing is far simpler and more constrained than with text. Too bad everyone only saw the downsides and shunned it, while the W3C kept pushing its SGML/XML/HTML-inspired formats...
Macromedia / Adobe thought they had something too valuable to share, so now it's dying.
Also binary formats aren't as great as you think for vector formats that need to work between software written by different devs who don't have access to each other source code. Problems become very difficult to debug.
EPS files are also text files.
At this rate, it'll become another html spec.
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.
This is pretty interesting where imgur has a http://imgur.com/r/gifs section but it's all mp4.
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.
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.
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!
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
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?
http://srufaculty.sru.edu/david.dailey/
He tends to post various experiments which continuously blow my mind, though also mentioned he preferred the 1.2 spec to 2.0:
(The fact that Ello supports display of SVG images helps.)
PS: CorelDRAW had it in 1992 and didn't need a CSS parser to do it.
XML is not good at describing structures or interfaces. It does not have precise semantics. The semantics of XML are so vague that you can't even tell whether whitespace is significant when parsing it.
XML describes marked-up text. And yet it's awkward enough that it's not even used anymore for the most common case of marked-up text (HTML), which is why SVG is evolving to be more like HTML now.
By comparison, HTML has almost no semantic. You have no idea what the code (which code, by the way?) is going to do with your 'article' tags or tell exactly how 'nav' is different from 'menu'; this spins endless debate about which tag to use. I remember how people argued that using 'dl' for figures with captions was, you know, "semantic markup" :) This is not semantic markup. Semantic markup would be things like <date:timestamp value="..." /> that a browser would render in my timezone or <chess:position move="white">...</chess:position> to describe a position on a chessboard so that a search engine could find similar positions or chess parties where this position has occurred. This is semantic markup and this could be semantic Web. And to make this happen we need to be able to develop small and clearly specified mini-languages with precise semantic (=computer instructions) and then mix them in a single document and this is what namespaces are for. This is the vision behind XML. It's very sad that few people grok it; most prefer to badmouth things they don't understand.
A proper markup language should either be low-level and describe, for example, physical layout and such, or should be extensible so I can describe the document in my own terms! I do not write a bunch of divs and h1s, I write, for example, docs for a function with <synopsis>, <parameters>, <examples>, maybe <notes> and so on. And then I mechanically convert it into a low-level language for rendering. HTML is neither: it's not low-level, it's very hard to control even the visual appearance, and it's not extensible either. It's bad in all aspects.
(Also, XML not only describes marked-up text, it's the only practical way to work with such text. All modern publishing uses XML.)
Okay, just because you don't like HTML5 doesn't mean you get to deny that it exists.
XML is the only sane format to deal with marked up texts written in natural languages, and this is precisely because it is extensible, so you can describe the structure in terms that make sense to the subject matter and still be able to process it with standard tools. It's also a perfect format for parsing results, because XML is essentially a frozen syntax tree. HTML is just a single fixed language; it's widespread and popular but not because it's technically superior (same as JS and CSS).
You seem to have missed the point of my reply. You said "all modern publishing uses XML", and in doing so, you were overlooking the biggest counterexample to XML, and the biggest thing in modern publishing, which is HTML 5.
HTML is a huge, huge example of modern publishing. It tried XML, when HTML 4 came along with XHTML. XML was basically designed around making XHTML work. And then HTML stopped using XML in HTML5. It took a revolt of all the implementers of HTML, but people got behind it because everyone could tell that XML wasn't helping.
So now you've got a syntax that was designed for marked-up documents, that people don't really want to use for marking up documents, and it's also trying to convey data structures despite that this involves horrible patches like "xml:space" that no other format needs.
You were also hinting at APIs for communicating things like time zones and chess moves. Real APIs don't use marked-up natural language. I work in natural language processing, and to a first approximation, computers don't understand shit about natural language. When you need to communicate data, you use data structures.
If you want to communicate extensible data structures with hints about their semantics, you've got some choices, like protobufs and JSON-LD. Or you can keep patching XML and trying to make it convey data structures despite that data structures aren't made of marked-up strings, but then people won't use your API.
XML is also an unwieldy format for parse results. It's not a frozen syntax tree, it's a tree with tons of stuff bolted on to the side. The format that represents a syntax tree is S-expressions.