I _think_ I remember hearing that the dedup would allow resubmission of things that didn't originally get much traction/upvotes/comments, so that might be at play here?
Maybe it was wishful thinking on my part, but there was a time when I hoped that svg would be to vector graphics what png is raster images. With svg continuing to gain complexity, all that hope is gone.
Try right-clicking on the .gif and select "show controls", if it's there. This works for me most of the time. It doesn't work at all for real .gif files, but it's true that most ".gif" files are actually auto-play looping videos with no sound and hidden controls.
Some important browsers still don't have a good video image story, and most SMS/chat systems are even worse.
We generate animated gifs for our 3D animated emoji and stickers.
I think what's really missing is an open binary vector graphics format which is compact and easy to parse. Adobe Flash's shape format is the closest I can think of at the moment.
You're right. SVG2 requires full CSS support. CSS brings lots of complexity, like calc(), CSS variables and so on. All that is needed, because web developers use SVG2 inline in HTML documents. It is also becoming more common to embed HTML in SVG. It's going to be one big tag soup. All that is better for the web, but worse as a stable image format.
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 saddens me a bit, actually. SVG had lots of features way before CSS and now they're forced to adopt them to not confuse people who use HTML/CSS. CSS to my knowledge never even tried adopting features in an SVG-compatible way.
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.
I think it's ridiculous that SVG has a complexity comparable with HTML.
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.
The way I see it is SVG is a format for humans (that's why it got all those shapes and tricky formats) and its main use-case is browser (so CSS and JS support is not a problem, because it's already there). There should be another simpler vector format for machines, IMO.
What would be the purpose of such a simpler vector format?
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.
> What would be the purpose of such a simpler vector format?
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.
The thing is, almost nobody is using SVGs on the Web. Usually wikipedia is cited as a website that uses them, when in reality they're rendering them to raster images. They actually have a nice site with the problems they're facing: https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_ima...
Other issues are that files might be bigger than pngs and have bad performance.
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.
Of course there are counterexamples but most websites aren't using SVG. Out of the Alexa top 20 only live.com is using svgs everywhere where they make sense and only yahoo.com is using them in some parts of the website.
I have gone in deep with SVG, rendering them inline with backend code that embeds locale specific text and hyperlinks. I am a big fan of 'use' and sprite-sheets. SVG everywhere is what I like, in fact I prefer to embed a PNG in SVG rather than using native images.
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.
Hey I like SVG too, even doing logos by hand with it. To this purpose I've created this: http://www.gamesfrommars.fr/live-svg-editor/
I have trouble making SVG use each other reliably though.
I use SVG graphics almost exclusively nowadays. Browser support is near-universal. Being able to use the same graphics asset in a wide variety of sizes and screen resolutions is immensely convenient. Rather than having numerous copies of a logo (small, large, retina etc) I only have to make one SVG version (and one PNG fall-back if IE8 matters).
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.
> PNG and JPEG files are also universally usable outside of browsers.
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.
My own intuition is that what is wanted here is a vector-graphics Abstract Machine instruction set in the RISC style, where an implementer only has to write and optimize code for a set of orthogonal primitives, and then everything else "falls out" of that.
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.
Many of your concerns are addressed by 2.0, go give it a look.
> 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>.
My general point is that SVG is an extremely complex format and that its complexity is preventing further adoption. Removing SVG fonts isn't going to change anything about that, as nobody but webkit bothered to implement it anyway.
> 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.
I really don't know what that "further adoption" you're talking about because it's on all major browsers. caniuse.com marks SVG support on 97% of clients worldwide.
You can't really use SVGs, except on the web. MS office, latex, ... all need conversion. This seems a minor issue at first, but companies will simply not bother converting their logos to SVGs for the web then.
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.
Well, yeah. You also can't really use HTML except on the web. SVG and HTML are both formats that are most at home on the web and in a web browser. It does that job well. It does a lot of things that are impossible or cumbersome in PNGs. PNGs are good enough for logos, I don't see why you would care either way.
You are forgetting that you can't AFAIK embed custom fonts so using them exposes you to the different way OS handle font-weight, font-face and friends. Soon the only programs able to open SVG will be the browsers.
Looking at the SVG2 spec it seems that support of embedded fonts is mandatory [1]. I'm not sure about the story in SVG. It's been supported wherever I've needed it and when parsing svg files myself I extract the fonts (which is easy enough with a simple grep / cut)
While I agree that multiline text boxes would have been great, Text on a Path is also useful on occasion.
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.
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.
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...
A W3C standard has to be open. Macromedia / Adobe used their EULAs and IP law to fight all third party swf renderers.
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.
They're deprecating "a xlink:href" and adding "a href". Sounds good to me. I never had any idea why it had to be "a xlink:href" except that this was designed when someone thought XML namespaces were a good idea.
With XML namespaces independent development teams can freely design their own structures and interfaces and then mix them in a very granular manner without danger of name clash. This promotes design and reuse of specialized mini-language with exact precise semantic. xlink:href is better than plain href because plain href is an informal convention, while xlink:href is code reuse.
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.
The semantic of a computer language (and a markup language in particular) is what the code does with it. Sometimes the code uses whitespace and sometimes it doesn't; XML doesn't enforce either way and leaves this up to the app. When necessary you can explicitly mark your preference in different parts of the tree with the 'xml:space' attribute. This attribute has precise and unambiguous semantic. It is also another example of why namespaces are important: it's a universal attribute that can be used with any XML document, by the virtue of namespaces it will never conflict with anything, it has a clear and small area of responsibility so any software vendor can easily implement it, you don't need to invent your own conventions or whatever, just reuse it.
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.)
Is that all you can say? It does exist, but it isn't much better than it was in v4. A few more canned tags; big deal. I wonder why the minor syntactic differences were so important though. Is it that hard to close a tag? And why no empty tags, they're certainly more concise? These are probably rhetorical questions. Sure HTML is superb; you still have to specify the time of your upcoming webinar as plain text so the users from other side of the world would have to look up what the WTF timezone is, but I'm sure there's a tiny half-megabyte JS library with a clever regex to fix this.
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.
I tried to use SVG on a recent project and did not have a good experience. The project was converting PDF building plans to SVG and then I had to do some transformation UI to align them to a map.
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.
I have a similar use case (http://www.countfire.com) and we've found svg to be really good. We often deal with documents with hundreds of thousands of Dom nodes. Admittedly we have limited ourselves to supporting google chrome so that might be the difference. Though we did also have to spend quite a bit of time optimizing the way svg manipulation is handled to make things performant.
Wondering how you feel about that? Was all the extra effort worth it in the end? Considering you only support a single browser anyway. Imagine a similar effort per browser. There's even a lot of variance between Chrome, latest FF, IE Edge, etc.
In my case I wasn't even manipulating the actual SVG nodes, just using transform CSS operations on them (transform and transfrom3d).
The final result is really nice. The user experience is smooth, and that's what matters most.
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!
We have a graph editing and display component, which is primarily built on SVG (canvas rendering available, too). Performance is rarely a problem. Admittedly, we do remove elements that are not visible from the DOM, for very large graphs those have to be tweaked a bit (same goes for WPF). Generally usability suffers before performance does, and most techniques of improving usability also improve performance.
David Daley of Slippery Rock University is involved with SVG -- I know his work mostly through his Ello posting, but you'll also find a pretty significant CV here:
Finally SVG has an over-engineered, bloated, complex machinery capable of emulating a conical gradient (hi-fi metal knob effect.) We can now retire and give up this life of crime.
PS: CorelDRAW had it in 1992 and didn't need a CSS parser to do it.
73 comments
[ 4.6 ms ] story [ 142 ms ] threadhttps://news.ycombinator.com/item?id=12254324
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 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.
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.
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?
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
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:
https://ello.co/ddailey
(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.