Having spent the last 3 years building complex visualisations with SVG, the biggest drawbacks I found are:
- Poor optimisation. Browsers have done a lot to speed up HTML + CSS rendering via the GPU, and you can you use WebGL to make canvas fast. SVG seems to have been neglected in comparison.
- No layout management. HTML + CSS isn't perfect in this regard, but you still get blocks + inline text, floats, absolute positioning, tables and flexbox (and soon, grids). In SVG, you get absolute positioning, and that's it. If you want to do any kind of complex layout, you have to calculate everything yourself in script.
I'm not sure the major browser vendors really care too much about SVG. Compare the huge advances made in other areas of the web platform with the years-long, incredibly unambitious SVG 2 specification process.
It's a real shame as as this presentation shows, you can do some incredible stuff with SVG. But it could be so much more if there was just a bit more effort invested.
I've also spent the last 3 years doing a lot of svg work. The experience is really enjoyable for me, as a coder it's great to know what's going on and make things work using maths.
My work involves working with huge svg documents (up to 500k Dom nodes) with a relatively well defined structure so there are lots of bits of svg that I'm less familiar with. Because I'm fairly sensitive to performance issues I've seen the work that goes on there and you're right, it's second class compared to html but there's still development happening.
The layout management is definitely substandard. It's a bit of a kludge but you can use foreignobject to put HTML inside svg and do the layout there. On paper it doesn't look too bad [0] but YMMV and I haven't played with it myself.
All in all I'd like to see more activity in the svg space. It's a great tool and with a bit more awareness I think it could have a great future in the web development world.
"using maths". that sounds like an entirely different solution than building interfaces, which is what this presentation was about. The example you cited with 500K DOM nodes.. Really? How as the browser performance? Why not just convert to canvas at that high level of DOM elements?
It is different but I guess my point was that SVG is a brilliant tool for developers. We (generally) approach problems in a programatic way, and SVG allows you to do that for graphics, which is incredibly liberating.
Performance is good! I've definitely had to come up with some pretty clever hacks but it feels smooth once the SVG has loaded. In our case we need to be able to zoom in to arbitrary levels and still have crisp vectors.
Here's an example of a document with about 150,000 dom nodes. You'll see that it's a little sluggish when you're zooming in and out but after it catches up it's really quick to move around. Most of our documents are much smaller than this so there's no real delay on zoom in those cases.
is it suppose to be device agnostic? I'm on a core i7 device so it's not a good indicator of how performant a given web solution is.
Generally speaking when you have that many elements, you've surpassed the threshold of what SVG is intended to do. Canvas can be a seamless replacement for SVG without any tradeoffs, other than additional build complexity
The problem with canvas is that our users need to be able to zoom very deep and still have crisp rendering. We wouldn't get that with canvas unless we rendered to a really huge canvas, right?
Yeah, the machine is definitely going to make a difference, though as I say a) most our documents are smaller than this and b) we have ways of speeding up bigger documents where required.
Sure, SVG isn't made for this, but it works. Going to canvas would mean a load of extra work and you can be sure there would be other tradeoffs and issues to work around. Additionally, SVG is super hackable. You can work with it easily front and back end. You can read it and understand what's going on.
i think you can redraw the canvas when zooming in. So even if the canvas dimension is finite, you can redraw it with infinitely higher resolutions of data.
I get the idea, but then I'll be doing the work that the SVG engine is currently doing. So really, here you're trying to get canvas to do something that it wasn't designed to do - which is weird, because that was your argument against svg in the first place. A quick google reveals the general solution of "sounds like you should be using svg." [0]
Given that svg 100% works for my usecase, I don't have any reason to attempt anything else at the moment. People give svg a hard time about performance and I think that's counterproductive. My suggestion is that everyone should give it more of an honest shot and I suspect they'll find that there are plenty of cases when it becomes the first tool they reach for.
Also what about editors?
In my experience writing graphics this way (via XML files) scares off 95% of the artists. Programmers can do it, but they make crap art. A designer who is good/interested enough in doing these is very rare.
So unless there is excellent support (can make animations, generates nice code,..) by Adobe products it wont catch on.
SVGO is interesting. One of my biggest complaints over the years has been that most tools that export to SVG do it in such a way that the file is so difficult to understand and edit that the results are useless.
I do frontend web dev in a big, mixed-media advertising agency. The logo's that we design for clients are created in Illustrator so they can scale to billboards or banner ads. The psd's that I receive for websites often contain icons done in illustrator. Exporting to svg is easy to do but yields code that is messy in the way that exporting a Word document to html is. It works but I'm not going to edit the code.
For what it is worth, Illustrator CC got an update on one of the .x versions (17.2?) that brought "Export SVG to Web" option that produces web quality SVGs (maybe SVGO exported even?), a huge improvement over the old Save As SVG route.
I routinely use Illustrator for fairly complex SVGs that are subsequently included in web pages, and the code is pretty serviceable. SVGO will clean it up a lot, but usually to the point of make it much hard to hand-tune.
dealing with `id="Layer1"` is annoying, but trivial. The endless nested `<g>` elements can be deleted. I've heard it's gotten better (I've neglected to ask for an update from CS6 for the past 2 years.
What is absolutely terrible is dealing with SVGs exported from Sketch. And that's all our UX/UI/Designers use these days.
For what it's worth the SVGs exported by Sketch are workable. I usually go in by hand and clean up the exports, but it's nowhere near as bad as old dreamweaver html exports.
It's less of an issue for visualisations, as if a designer creates a mock-up, it's only used as a guide for implementation by a programmer, rather than an actual asset.
However we have used Sketch's SVG export for things like icons, and I've found it to be pretty good. There's even an CLI export tool than you can integrate into your build process.
> In SVG, you get absolute positioning, and that's it. If you want to do any kind of complex layout, you have to calculate everything yourself in script.
Depends on what you mean by absolute. The current transformation matrix (CTM) in each group hierarchy is computed relative to the parent element.
We've experimented with this, and it can help, but it's not a silver bullet. For example, we had a stacked bar chart where we used a horizontal flexbox for the core of the chart. Each entry in the flexbox was a separate SVG. This let use do nice things like set a minimum size for each bar and have the chart overflow and scroll if there wasn't enough space to draw all the bars.
But then we got a requirement to overlay a line chart on the bars. And that meant layering a separate SVG on top, and doing a bunch of script work to make sure everything lined up correctly. E.g. detecting when the window resized, or when the content overflowed, etc.
It worked, but the resulting code is not at all fun to work with. The frustrating thing is the that the layout is trivial in pure HTML + CSS, and the graphics are trivial in pure SVG. But neither has the complete story, and so you end up having to jump through so many hoops, when it feels like it could be so much easier.
Is it worth investing that effort, though? WebAssembly has entered its public alpha on multiple browsers and is coming a long way. It'll make WebGL easier to use and will probably give rise to other graphical UI APIs that run directly in the browser. Does SVG still have a place in a WebAssembly world?
I don't know, but I really, really don't hope we get to the point where every web application ships a bespoke, WebAssembly rendering engine and treats the browser as WebGL dumb terminal. That sounds like a complete dystopia.
Think loading times are bad on script-heavy websites now? Wait until every web app uses its own mix of graphics, font and layout libraries, all compiled from C/C++ to WebAssembly and shipped in a 100MB blob. And rendered without any integration with accessibility technologies, and with basic things like copy and paste disabled to stop you "stealing" content. No thanks.
That'll be the first step. Then people will notice all those crazy download times, and someone will figure out that things could be better if they could write a single reusable "container" app in WebAssembly and WebGL that could host nearly arbitrary content, described in some kind of high-level markup language that's reasonably concise...
Neither WebAss, nor WebGL (nor the canvas API for that matter) is a vector graphics format. When using WebGL, you still need a way to integrate complex prepared graphic content. You could implement an SVG renderer in WebGL + JavaScript I guess, but that's certainly not easier than just using SVG content straight away.
SVG 2 leaves the "painter model" behind (where z-order is determined by document order of the respective shape within its container) in favour of the z-index CSS property, so that you can address it in CSS (eg. `:selected { z-index: 1 }`). This makes it possible to describe things like interactive maps and DVD-like menus where when you click on a shape, the shape gets scaled or applied some other transform for highlighting.
However, I agree that SVG 2 leaves a bit to be desired (for example, level of detail properties). Also, animation of SVG in FF sucks compared to Chrome and Safari, or at least it used to 3 years ago. I wanted to teach my 12-year old how to make a simple browser game, but had to resort to hackish workarounds to make it run smoothly on top of using rAF etc., ruining my pedagogical ambitions.
> Also, animation of SVG in FF sucks compared to Chrome and Safari, or at least it used to 3 years ago.
I can relate to this, I use to work on a svg-heavy project in 2014 and I had the same kind of issues and I filed many bugs on FF bug tracker .
Fortunately, they've all been fixed by the mid of 2015. I don't work with svg so I don't know if everything works well now, but at least there were improvements.
That's a great point. I bet WebAssembly will result in an altogether next generation of technology given what we want to achieve today, not what we wanted to achieve in the early 1990s. But I have a feeling svg will have a big roll to play, and not only as inspiration either.
Given that we see more and more desktop applications being built with web technologies (formerly with node-webkit and recently with electron), and new UI toolkit are not really popular projects right now, I really doubt that many people will develop/use a brand new UI toolkit built on top of wasm and webGL.
- Poor optimisation. Browsers have done a lot to speed up HTML + CSS rendering via the GPU, and you can you use WebGL to make canvas fast. SVG seems to have been neglected in comparison.
- No layout management. HTML + CSS isn't perfect in this regard, but you still get blocks + inline text, floats, absolute positioning, tables and flexbox (and soon, grids). In SVG, you get absolute positioning, and that's it. If you want to do any kind of complex layout, you have to calculate everything yourself in script.
I'm not sure the major browser vendors really care too much about SVG. Compare the huge advances made in other areas of the web platform with the years-long, incredibly unambitious SVG 2 specification process.
It's a real shame as as this presentation shows, you can do some incredible stuff with SVG. But it could be so much more if there was just a bit more effort invested.