SVG is too complex/heavy for simple tasks and actually is not that good for complex tasks - more or less complex image requires special editing WYSIWYG application to create it.<p>Let's imagine that you need to render simple icon using CSS that should change color on :hover:<p><pre><code> div.icon {
background: url(simple.svg) no-repeat;
background-size: 1em 1em;
}
div.icon:hover { ??? what to do here to change the color ??? }
</code></pre>
Just to render this thing you will need: to download the file, parse SVG, build DOM tree and "play" that DOM tree on canvas. Each task is not trivial.<p>While ago I've proposed at w3c-styles simple and lightweight solution for vector images and shapes in CSS - so called path URLs:<p><pre><code> div.icon {
background: url(path:c 50,0 50,100 100,100 c 50,0 50,-100 100,-100) no-repeat;
background-size: 1em 1em;
stroke: #000; /* vector stroke color */
}
div.icon:hover {
stroke: #F00;
}
</code></pre>
The path uses the same format as "d" attribute in SVG's <path> element:<p><pre><code> <path d="c 50,0 50,100 100,100 c 50,0 50,-100 100,-100" fill="#000" />
</code></pre>
Parsing is trivial and rendering of such "images" is just a set of primitive drawing operations. No DOM or anything like that.<p>More on the subject (with illustrations in Sciter) : <a href="http://sciter.com/lightweight-inline-vector-images-in-sciter/" rel="nofollow">http://sciter.com/lightweight-inline-vector-images-in-sciter...</a>
Look no further than D3.js as an example of the kind of visualisations which are possible with SVG.<p><a href="https://github.com/d3/d3/wiki/Gallery" rel="nofollow">https://github.com/d3/d3/wiki/Gallery</a><p>At least this is what introduced me to working with SVG. As much as I like D3, mainly for charting, it's not the easiest thing to pick up.
SVG is amazing, my main concern about it. it is because it creates a huge burden to browser developers. The spec is <i>huge</i> [1]. And some parts are outdated[2].<p>[1] <a href="https://github.com/WebKit/webkit/tree/master/Source/WebCore/svg" rel="nofollow">https://github.com/WebKit/webkit/tree/master/Source/WebCore/...</a>
[2] <a href="https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animation_with_SMIL" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animati...</a>
I am using svgs in a project now.<p>- The first issue was the designer Im working with didnt know how to export to svg.<p>- Second problem is my svgs ended up with very weird numbers and groups. Such as the main groups offset was -60, 190 then another group to dlightly compensate. Then the paths themselves compensated further.<p>- Another issue is "cutouts" are nonintuitive for designers and also complex to reverse when they are curves.<p>- Another issue is linking and styling to an external svg. Despite you can put them in an image tag, it cannot be styled this way. If you put it inside a use tag, styling externally requires targeting ids.<p>- anothwr issue is that they dont follow the normal rules of width/height. By default they are 300x150 and takes a bit of patience to ensure they exist as 100% width (which I assumed was default)<p>Other than that, I am quite pleased with the format and am expecting great things for it!
SVG also has more risk: stored XSS, which isn't something you'd expect from a file whose MIME type starts with "image/".<p><a href="https://github.com/w3c/svgwg/issues/266" rel="nofollow">https://github.com/w3c/svgwg/issues/266</a>
When I first heard about svg, I was excited. Finally everybody getting behind a vector graphics format... and since then the more I see the worse it looks. A boosted, text-oriented, JavaScript-enhanced resource monster. All the worst attributes of HTML, but in vector graphics.<p>Did anybody want this? I know I wanted a jpg of vector graphics - a resource-friendly small system for embedding vector graphics into things. Something where I don't have to worry about an image having an xss vulnerability. Something that degrades gracefully so it can still work in some form on an anemic piece of equipment.<p>But no. We throw bigger and heavier hardware at more trivial problems.
SVG as a representation language for draw programs is pretty good. Most draw programs don't utilize it fully. While SVG can represent dimensions as inches or mm, most programs only support dimensions as pixels, which makes SVG useless for CAD drawings.<p>If you need drawings with lines and boxes, Inkscape is very helpful. Most drawings in Wikipedia are in SVG, and many were drawn with Inkscape. You can update drawings in Wikipedia by bringing them into Inkscape and editing them, then checking them back in as an update. It's not a read-only notation, like Postscript.<p>Manually tweaking SVG text, though? Painful. It's encapsulated like XML, so you can, but you probably shouldn't. After you've done that, most draw programs won't be able to handle the fancy stuff. And really, drawing by typing text is like pounding a screw with a hammer.
Timing! I just pulled a 4AM night last night creating my first ever Lua library, <i>svglover</i>[0], to facilitate SVG display in LÖVE[1], for a roguelike. Motivation was primitive[2] posted[3] last week. It's actually pretty easy to work with, even for lazy coders who find regex parsing acceptable like me[4] :) I'm no oldschool demo coder, but the coordinate transformation system is basically just a simple layer on top of an OpenGL pipeline. You don't even need viewbox, just groups with <g></g><p>[0] <a href="https://github.com/globalcitizen/svglover" rel="nofollow">https://github.com/globalcitizen/svglover</a> [1] <a href="http://love2d.org/" rel="nofollow">http://love2d.org/</a> [2] <a href="https://github.com/fogleman/primitive" rel="nofollow">https://github.com/fogleman/primitive</a> [3] <a href="https://news.ycombinator.com/item?id=12539109" rel="nofollow">https://news.ycombinator.com/item?id=12539109</a> [4] <i>Make it work first, then make it work fast</i>.
Gordon Lee[0] has made a ton of sophisticated SVGs for Wikipedia and its projects and recently presented at Wikimania. The Burj Khalifa[1] is one of my favorites. Inspired, I wrote this short script for fun that chops up a Blender file into PNGs[2] which I used to generate an animated SVG.<p>[0] <a href="https://en.wikipedia.org/wiki/User:Cmglee" rel="nofollow">https://en.wikipedia.org/wiki/User:Cmglee</a>
[1] <a href="https://upload.wikimedia.org/wikipedia/commons/0/06/Burj_Khalifa_floors.svg" rel="nofollow">https://upload.wikimedia.org/wikipedia/commons/0/06/Burj_Kha...</a>
[2] <a href="https://github.com/rndmem/ndice/blob/master/blend/d/render" rel="nofollow">https://github.com/rndmem/ndice/blob/master/blend/d/render</a>
SVG works for the trivial graphics use cases that are presented. But it falls apart for anything that requires more complexity, or dealing with documents of arbitrary complexity.<p>There is little provision for incremental rendering, and poor control and visibility of the internals of the rendering process. Once you dump your SVG to the browser, that's basically it. There's no way to find out what is going on.<p>It's really nice to just set a break point in your imperative Canvas code, or WebGL code and see exactly what is happening, and use all the standard debugging and profiling techniques. I have yet to see the same for SVG.
Three years ago I was amazed by the versatility of SVG when I discovered it through D3 and it inspired our graphical designer to ask us designs never before seen in SaaS applications. Once you're willing to dive into the specifications, you'll find a treasure trove of possibilities.<p>There are some caveats beginning users should be aware of. First of all, better forget multi line text or sophisticated text layout within the SVG. I still think that's really missing in the current specification. As a commute project I once wrote the dynamic programming layout of Knuth (used in TeX) for SVG and JavaScript, but it was slow and didn't allow for multi line selections.<p>Another problem is rendering speed. SVG renderers can be fast, but you have to know what can be optimized by the gpu and what requires the CPU.
Annoyances with SVG:<p>- Modularity is tough: you can nest <svg> or <g> elements with various transforms, but there's no first class layout concept.<p>- Pixel imperfections: browsers don't always render things 'nicely', and all sorts of horrid aliasing can happen.<p>- Styling options: all sorts of simple stuff like a double outline of a shape is really difficult (without extremely complex filters)<p>- Export: taking an SVG and exporting it as an image has lots of complications, especially with embedded fonts.<p>All that said, the output is mostly okay, and it's possibly the easiest graphical technology to integrate with React-style frameworks.
I'm wondering if it would be possible to parameterize SVG files. Suppose I have an icon in the file "icon.svg", it would be awesome if I could say in the CSS:<p><pre><code> .icon:hover
{
background-image: url("./icon.svg") main-color=#ff0000;
}
</code></pre>
where "main-color" is a parameter of the SVG file. So the icon turns red upon hovering (just an example).<p>Is something like this possible?
I really like SVG and this was a great article that contained many things I didn't know.<p>That said, I _tried_ to use SVG for something as simple as displaying some multiline monospaced text with whitespace preserved, and found it's either really hard, or actually not possible (unless you position each glyph manually). Is that really the case?
SVG has another interesting application: it can be used as a UI language for graphically rich and complex interfaces, almost game-like but not quite. You often see this kind of interfaces in audio, i.e. soft synths/effects. Though you will need to create your own extension to the markup and a subsystem that supports it in your OS, which in the end is not too complicated.<p>(Shameless self-plug as an example of an SVG-based GUI: <a href="https://itunes.apple.com/us/app/magnetola-vintage-cassette/id1027234156" rel="nofollow">https://itunes.apple.com/us/app/magnetola-vintage-cassette/i...</a>)
As a designer using SVGs across the web, there are a few drawbacks that are easy to fix:<p>- platforms like Twitter and Google Slides not accepting SVGs. I assume this is due to security concerns.<p>- Using SVGs on a website doesn't render with included WebFonts like normal text would. This leads to outlining text, which is a huge maintainability burden.<p>- Graphics programs have tones of SVG bugs. Even "leading" software like Illustrator and Sketch have a lot of bumps in the road.<p>Overall really excited about SVGs and use them as much as possible.
The main problems I've experienced:<p>* SVG's performance degrades sharply after a few hundred objects, then you have to use canvas or WebGL, or prerender to images
* browser differences<p>otherwise good
Generally I agree that SVG is awesome, but there are a variety of cross-platform issues with it and I worry it does not get enough serious use to see them addressed. The status quo is pretty good, but if you run into issues there is not always a work around.
I'm quite excited for SVG absolute positioning to become available in all browsers. It'll mean real responsive images, not just resizing, being able to move parts of the SVG instead of scaling proportionally, as the image is resized.
The issue that makes me not enjoy working with svg is the lack of negative scaling values. It makes it hard to do complex transformations on your vector widgets. Canvas is so much more better.
This is why d3-node is the way to go...
<a href="https://www.npmjs.com/package/d3-node" rel="nofollow">https://www.npmjs.com/package/d3-node</a>
SVG? Wasn'it the new tech (10 Years after ARM) in 2000 that was supposed to be so wonderful it would be very easily adopted?<p>We are in 2016 ... ARM are still promising and SVG is still the new promising thing. Well, SVG has not taken a wrinkle, nor grown up a lot. It is still overpromising and complex.<p>Let me watch my backyard cristal balls for new innovations..<p>DCOM and RPC maybe? Oh, crumbs, it is called the cloud. All FW problems solved by using HTTP with cookies that are so safe.<p>I can't wait for the next new thing... GUI, Universal Display format (aka display postscript from NeXT), Xanadoo, XUL, sprites, linear framebuffers with blitters?