During CSSConf 2014 I was encouraged to give a B-track presentation following Sara Soueidan’s talk on SVG earlier that day. Together with the video above, I’ve added a full linked transcript (since YouTube the auto-caption algorithim apparently renders my hybrid accent as Martian) and resource list (also available in the ). The presentation is divided roughly into thirds:

  • setting up drawings in and exporting them
  • cleanup of SVG code
  • rare or unappreciated uses for SVG

The talk was very last minute – I had been ask to do it just the night before – so please excuse the poor quality of the slides; I’ve also added small corrections and clarifications in the transcript.

Transcript

Hey. My name’s Dudley Storey, and I’m here as last-minute request to back on the excellent presentation by Sara Soueidan on SVG. To make a long story short, Sara was originally going to talk about Shapes, and I was originally going to talk about SVG. She got in, and I didn’t quite get in, but then she changed her mind… so I’m going and try and do an accessory topic to (hers), featuring a little bit of my own work and talking about some of the things Sara didn’t have time to address. I would recommend that if you’re watching this now that you go see Sara’s first so that you can get the basics.

I’m going to start off with just a little bit of perspective. I am Dudley Storey (@dudleystorey on Twitter) I have a blog where I write about web development, and by trade I am a web development teacher. That’s what I do: I teach full-time, part-time, and night classes. I’m also a writer: I published Pro CSS3 Animation through Apress last year. I’m also a contributing editor to Smashing Magazine: I do their coding section.

So: SVG. SVG’s been thought of, and debated, and worked through as this foreign thing: this foreign, not terribly understandable, kind of battle against CSS. And it’s really not right. We really shouldn’t think of SVG and CSS as being enemies, or even frenemies… they really are two parts of the same side. Don’t think of them as battling each other: think of them as one tool, like a kick-ass lightsaber, that are joined together. I’ll show you ways that CSS and SVG – and, ultimately, HTML – can really start to complement each other. They’re not always just “Oh, it’s only just SVG” or “It’s only just CSS” – the two do start to work together in very interesting kinds of ways.

I’m going to give a very quick breakdown of a couple of things people need to do – again, Sara covered a little of this, but I’m going to do an addition.

Adobe Illustrator Workflow for SVG Production. If you know that you’re going to be using Adobe Illustrator to export to SVG then there’s a couple of things that you do want to do. You’ll want to set up your canvas in pixels: that seems kind of weird at first, as SVG is meant to be this scale-free, doesn’t-matter-what-kinds-of-units-you-use (technology), and that’s true, but it’s easiest if you set up canvas first in pixels because it’s the easiest thing to relate to: it doesn’t mean that your SVG is limited to a certain pixel dimension, but it does help move things across, work out where components are, that kind of stuff.

The artboard (in Illustrator) is going to become the viewbox of the SVG. Although the viewbox does a lot of things in SVG, (it’s) essentially the visible area of your SVG. So if you want to do things off-canvas, that’s perfectly fine, just make sure your artboard is a certain size. If you want to make it larger, that’s perfectly fine too. Just be aware that the two (artboard and viewport) will match up by default in Illustrator.

SVG in Illustrator will set itself up to be CMYK: don’t make the mistake that generations of people have made using these tools when you really want RGB in most cases.

The way that I like to think about SVG is that you’re making drawings as data: you’re not just making pretty lines, you’re not just drawing curves. So as you build things, give them some sort of naming convention (with id or class attributes). Any kind of naming convention is fine, so long as it’s consistent and you stick to it. Name everything as you build it: while it’s not absolutely necessary to do so, it becomes a whole lot easier later when you’re drawing to manipulate that as a pure SVG.

Simplify: as a rule, use the fewest number of points to create a shape. Again, a lot of people will start to use (many points) to get the shape they want on screen. Don’t do that: try to use the fewest number of points. Try to avoid filters in Adobe Illustrator, as they’re not yet translated into SVG when exported. Don’t stroke things if you don’t have to: stroking will add another level or layer to your SVG that you really don’t need. If you need it, fine, but if you don’t, make sure it’s not there. Try to keep polygons and circles as geometrical objects: don’t try to break them apart. Create a background if necessary: understand that (the background of) SVG elements is transparent by default: they’re automatically alpha-masked, which is awesome, but it means that there’s no “body” to an SVG file. You can do that in the body of your HTML page, where the SVG is obviously going to be used, but you can’t do it in the SVG itself, short of drawing a giant rectangle at the back of the whole artboard. You can kind of, sort of, do a background on the SVG using CSS (once the SVG is embedded into your document) – it’s possible to do, although you have to be a little bit careful about it.

Before exporting from Illustrator to SVG, try to merge shapes using Pathfinder tools. Again: fewer elements, simpler elements, better: it doesn’t mean your SVG can’t be complex, doesn’t mean it can’t involve a lot of elements, but obviously the fewer things you have the better.

Decide how you’re going to treat text: it’s important to understand that SVG can have text as text so it’s readable, styleable, and everything else, but with the downsides that we’ve experienced with real text on the web forever: that is, you might embed a font that doesn’t load. So SVG text has all the same problems in that regard. Or, you can break it apart into outlines. The downside of that is that (the text is) not readable anymore: it’s purely path information. So make a decision: is this going to be readable by Google (in which case) leave it as text, style it, and understand that styles might not be applied in every circumstance. Or: you want the (text) to be exactly the way it appears, but you don’t want it readable by anything, but you want it manipulatable so you can move points around, then break it apart and convert to outlines.

Finally, crop the artboard – there’s no point in having areas that you don’t need – and export to SVG. One thing to keep in mind about that: Adobe Illustrator CC kinda sorta lies to you. It does allow export, but Adobe Illustrator CC has a new “make responsive” feature that’s not totally true: it does it part of the way by removing the height and width elements, which I’ll get into in a little bit, but it doesn’t really do do everything you need it to do in most circumstances, so take the feature with a grain of salt.

Illustrator has an option to reduce the number of decimal points used in the exports: (i.e. the accuracy of) the position of each little element and point in the SVG drawing.  You don’t need 3 decimal places for drawings in the vast majority of circumstances; all it does is increase file size, making the SVG file larger and longer. If you possibly can, reduce the number of decimal points, ideally to 1. All of this stuff can ultimately done in post-processing, using some of the tools Sara talked about, but why post-process something if you can get it right the first time?

Basic SVG cleanup: again, Sara was talking about how to make SVG “clean” using tools, and that’s good to know and important. What’s also good to know is what those tools are actually doing: it’s not terribly complicated for the most part, and if you know a little bit about what they’re doing, you can do the same thing by hand if the tool doesn’t work, (as well as) understand what might go wrong.

Generally speaking the export of SVG from Inkscape, Illustrator or other tools will be extremely verbose: there will be a lot of information in there. While it’s not wrong, it’s also unnecessary, and you can usually save yourself space (by removing it). Things you don’t need, unless you’re doing some kind of deep dive into the SVG document: you don’t need the XML prolog (or) the doctype. You do need the namespace information, mostly because without it the SVG file is going to be invalid, so you may as well leave it in. version you don’t technically need. width and height, for the most part, are what get people a little screwed up because they think (the attributes) are what’s constraining (the SVG), and get it confused with the viewBox, and they try to take the wrong one out. For now, take width and height out: note that nothing has changed. You don’t need id on the SVG element itself unless there is a whole bunch of SVG elements on the same page. At the same time, of course, make sure that everything is still valid and still working. Don’t need <def> elements very often, unless (they are) defining filters. Do be careful about group transforms: you’ll very often find empty groups that don’t actually do anything, which can usually be removed. If they’re groups with id (attributes) or transforms on them, leave them the heck alone: you don’t want to play around with them, because removing them will change or spoil your work.

I started off talking about the fact that SVG and CSS are really copasetic, so let me demonstrate a couple of ways in which that’s true. You can see that by default most tools will put lot of (SVG) styles inline. It doesn’t need to be inline, at all. You can do the same stuff you’ve always done by doing an embedded style tag inside the SVG, and that style tag can contain the vast majority of the CSS that you’re used to: it can contain @media queries, it can contain comments, it can contain most of the stuff you’re used to. Again, Sara did a very nice little screen of what (SVG) will take, what it can’t take, so there are some exceptions, but for the most part, the CSS you’re used to can be applied.

Here’s where it gets interesting: our path has an id of path1; let’s just change that, let’s call it jedi. So our path has an id: if it has an id, it can be addressed like an id, or a class, or most anything else that you’re used to (in CSS). It’s a fragment – it’s a piece on the page, a part of the DOM. We don’t need even-odd, we don’t need stroke, in this case.

[Presenter removes even-odd and stroke attributes from SVG code]

We can take many – not all, but many - of the style attributes from SVG and apply them as styles in CSS. That starts to make things really neat: it means we can use any CSS – color, in this case – associated with that style.

[Presenter applies a hexadecimal color to the fill style for a path with the id of jedi in the embedded style sheet]

Students I teach get a little confused the first time I show them this, saying “Does that mean I can now go into my HTML page and (use a rule like) div { fill: red} ?” No, you can’t. It’s only applicable to SVG, but in that context it’s perfectly understood and perfectly reasonable.

(Almost) all the CSS you know can be applied: let’s say hsla.

[Presenter changes the fill value to an hsla color]

Any hsl (value), any colors, and (CSS you want to apply, you can do, you don’t have to stick with hex(idecimal).

SVG has opacity, (which) you can use in just the same way you can in CSS: you can do hover effects just as you would in CSS. Let’s say we hover over an element with a fade; of course, you can transition that as well.

[Presenter adds a :hover pseudo-class to the SVG element, reducing its opacity to 0 over time with a CSS transition]

There’s a few interesting things to note about this: SVG is defined by shapes, not the box model you’re used to. If this was a PNG, as soon as (the user) moves (their cursor) over the area of the thing – the rectangular box that contains it – then it’s going to activate. But in SVG, (the box) doesn’t count: I have to be over the shape in order to activate it. That means very precise pixel responses. We’ve all seen icons (of) circular shapes with the problem that (a) move outside the circular area turns or clicks (the UI element), and that’s a misregistration. One of the advantages of SVG is that there is no misregistration: if you make a shape and say “this shape is a link” or “this shape has a hover effect” the shape registers, which makes SVG really powerful and very good.

One thing you have to be aware of is that CSS written inside the SVG will affect the appearance of the SVG but not its interactivity; in other words, you can’t write a hover rule inside an SVG and then take that SVG as an image and put it on the page. The appearance will work, but the interactivity won’t. If you want the interactivity you’ve got to place the SVG as an <object> or embedded inside the HTML.

A surprising number of people in the conference in the conference we’ve just been attending don’t know about SVG filters, or using filters in general: there was a quick little (show of) hands, and very few people were using them. That’s surprising to me, because one of the things that we’re talking about is… loading pages as quickly as possible, the interactivity to be as snappy as possible, and (reducing) our workflow.

People (associate) filters with -webkit, and understandably so, because they’ve been in there for a couple of years now. While they went through a couple of changes in terms of the spec, you can absolutely do filters in that way. But not too many people know that the same filters were built into Internet Explorer until IE9, and very often (those filters were) very simple. Modern Safari and Chrome are covered with CSS (filters), but unfortunately other browsers haven’t integrated them yet (or at least not entirely), IE9 and earlier is also covered (with proprietary MS filters), but what about Firefox?

Well, in Firefox, we can use an SVG file; the world’s simplest SVG, it’s tiny. In this case, it’s a color matrix. In this case you don’t need to understand it totally – it’s matrix math, no big deal – and pop it into a page, or as a separate file, (or an inline reference). What does it do? Very simply, it’s a bit of SVG that does the same job (as a CSS filter). In this case, the filter has an id of greyscale. So the nice part about this is, you now have the same effect, and it’s one of the very best examples of progressive enhancement: unless you or your client are real sticklers for “everything has to look exactly the same in the same way (across all browsers)”, generally speaking people aren’t going to be hugely upset if they are in IE10 and don’t know that the thing is meant to be in back-and-white and transitioning into color later, and they just see a color version because IE10 is between a rock and a hard place – it doesn’t yet support CSS filters or SVG filters, at least in this way, so it’s in a rocky place at the moment – but if they’re not aware of that, that’s fine.

The advantage is, you can load one image once. You want to turn it into greyscale, that’s perfectly fine: you add a filter and it’s done. You don’t have to load multiple versions of the image, you don’t have to have multiple HTTP requests, you don’t need to do weird things with image sprites: it’s just done.

You can do the same thing with blur; again, traditional Microsoft blur filters, which work in IE9, modern blur filters, in terms of –webkit, and blur in terms of SVG, (all of) which can be transitioned as well. Sepia toning, as well.

A couple of other areas in which people don’t necessarily understand that SVG can be used: imagemaps. Anybody who’s been around on the web for 10 years plus will remember imagemaps. They went the way of the dodo – they’re not responsive, they tended to use big, large images – but they still had their place. They were actually really good for touchscreens, especially for kids, because they could see them, they could touch the pictures, and navigate away from there. The problem was they’re not responsive, at all. SVG you can absolutely make responsive: you can put a bitmap image in the background,  and (make a) hotspot that will exactly scale with the picture as it moves up and down, which is really neat. Animated imagemaps: using clip areas, you can clip out bitmap photographs using paths in SVG. Because it’s pixel-perfect registration, you can then animate those areas as well as link them inside. (I) had an article in .net magazine a couple of months ago about the same technique if you want to read up on it.

Perhaps the most fun is adaptive illustrations, which are the idea that you that you can do @media queries inside of SVG. A lot of traditional use of SVG and responsive design is making things smaller – again, nothing wrong with making things smaller, rearranging them, placing them in different orders, that’s perfectly fine. What’s somewhat unexplored, I think, is the concept (that) we don’t just need to make things smaller; we could also do things like remove elements, because each fragment is definable inside that SVG, you can absolutely remove them with @media queries and simplify designs, not just say “this thing has to get smaller”, or “this thing has to switch to something else”, but literally simplifying diagrams on smaller screens: simplifying tree diagrams on smaller screens and you don’t want users to zoom in and out.

Very finally: the CSS spec for gradients is meant to have animation: it’s meant to do it. Unfortunately it doesn’t: to my knowledge, no-one (except IE10+) supports it yet, which is really unfortunate. However, SVG has supported animated gradients for ages, for ever. So: you can start to do really interesting work by animating the actual gradients: you have to use <animate> tags inside of SVG, (which are) not too  dissimilar to the concept of transitions, so it takes a little bit of getting used to, but it’s not too dissimilar. So you can finally – this is a 24-hour sky animation – you can finally start to animate gradients, which is wonderful, and there’s a lot in there. Eventually, of course, this will be supported in CSS, but if you need it right now – if you want the animated gradient – do it in SVG.

That’s all the time I have: I hope this was helpful. Again, if you have follow-up questions, by all means ask me on Twitter, follow up on the blog, and I hope to do a fuller and more complete A-track presentation in a future CSSConf.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.