 Good afternoon. So as Faldina hopefully introduced, my name is Amelia Bellamy-Royds. I write books about SVG and various articles. I have been spending a lot of time this past year working on the SVG standards and every so often I'm actually lucky enough to make cool things with SVG on the web. And just if you want to tweet me at Amelia's brain and these slides are already up on GitHub pages if you want to follow along. So I called this talk today the great SVG retcon. And in good web standards practice I'm going to start by defining my terms. Now what is great? What is SVG? And what, pray tell, is a retcon? Well, great in this particular context is mostly in the sense of big. It might also be in the sense of good but you'll be the ones to judge that. SVG in case you hadn't figured it out by now is a scalable vector graphics. It's a language for describing images on the web using markup and style so it's compatible with HTML and CSS and other web technologies. And retcon, well, that's where it gets a little more complicated. Retcon is a word that I borrowed from the comic con word world of comic books and science fiction movie franchises. But the con and retcon doesn't stand for convention or conference, it stands for continuity. Continuity in the sense of a story that continues smoothly. And continuity in those science fiction world is something you really talk about in the sense of broken continuity. So for example, maybe you've got a big action movie sequence and somebody's costume gets damaged. And then the next shot, the costume is perfectly fine. So maybe Captain America has this amazing self-repairing costume or maybe they just messed up with many, many shots and all being edited together. And it's a little detail and lots of people wouldn't notice but some nerds notice and they have websites like moviemistakes.com to report all these mixed up errors. Now, the ret in retcon, that's retroactive. Because sometimes you have to go back and fix the past. And specifically you're retroactively fixing continuity. You're creating something in your story now that changes how the previous story is being interpreted. Now, why would you do this if you have a successful storyline? Why would you want to change it? Well, usually because you want to move the story forward in directions that you hadn't thought of when you wrote the first episode or whatever it was. For example, maybe you've had successful movie franchise and you decide you want to spin off television show and the spin off television show is going to start everybody's favorite character actor who is a supporting character in the movies. But see, there's just a little problem. The problem is you killed off that character in the last movie. Oops. So what do you do? You retcon it. You make up this new storyline that yes, he died sort of but then he was brought back by this top secret technology. But it was top secret so either people were pretending he was still dead or they actually thought he was still dead. And that's how come Agent Coulson is dead in the Marvel movie universe but he is leading a team in the Marvel TV universe. And it all makes sense. You can move forward. And at this point in the game you're probably wondering now what does this all have to do with the web in general and SVG in particular? Well, continuity is even more important in the web than it is in movies. You can reboot movies. You can have a new Spider-Man series and it starts from the beginning again and everybody's okay with that. But you can't reboot the web. The web is out there. It's existing. It's continuous. You can't just change it all at once. This is different from other programming environments. If you're programming on server side or if you're building something that you're going to compile as a binary that ships to your customers, you control the environment. You control the language you use. You can switch any time. It's also different from JavaScript libraries because even though JavaScript libraries are on the web, you as the website developer get to decide which version of a JavaScript library you're pulling in. And so the libraries can update with new versions that have breaking changes. And so long as they warn you that they're going to be breaking changes, you as the website developer can wait. And when you have time to refactor to the new version, then you can update. But you can't reboot and version and break the content that's actually going to be read and interpreted by the browsers because you don't control which browsers see your website. Now, rebooting the web has been tried before. That's basically what XML was. Suddenly a bunch of serious programmers looked at this horrible mess that was the web in the 90s and said, oh, we've got to get some structure in here. But problem with XML was that all the browsers still had to support HTML because they had existing content on the web that they wanted their users to be able to access. And all the web developers still had to support old browsers. So they also continued to use HTML because after all the other option was opting into beautiful error messages like this or like this. And these were kind of useful in a world before DevTools, but they were kind of awful if you made one typo and this is what your end users saw. So XML kind of died and web standards makers learned from this. They learned that you've got to focus on continuity. You can't just tell everybody to upgrade to a new version of the web. So new standards are always built in this focus on continuity. The browsers as much as possible unless there's major security concerns still support all the old features. And new features as much as possible are designed to allow good fallbacks, assuming the people creating the websites use the options for fallbacks. For example, we have the picture element. And the picture element is all this cool new functionality, but at its very core, it's just a basic IMG element. So if you send all that modern picture element markup to an old browser, IE8 or something, it's like the far side cartoon of where you're talking to a dog and it's just blah, blah, blah, until it gets to the point where it actually understands something. That's your IMG tech. Now, this brings us to SVG2, which as I said, I've spent way too much of the past year working on. Now, SVG2, as of two weeks ago, is a W3C candidate recommendation, which basically means that those of us who've been working on it and people have been working on it a lot longer than I have are done fussing with it, and we really want the browsers to implement it so we can fix up any last bugs and get this stable and usable for you content creators. SVG2 has a number of interesting new features, which I'm not going to really talk about too much today because they're not out in browsers yet, so you can't really play with them much. But there are a few features that you can start. I should warn you, there are also drop features, which goes against everything I've said about continuity, but the features from SVG1 that have been dropped are all ones that were never web compatible anyway, which means that there was at least one major browser that either didn't support them or their support was so buggy you'd never dare use it. So lots of these things have been used, but chances are unless you're a total SVG nerd, you won't notice anything missing. So what I am going to talk about today is not either of those aspects, but rather some more central core changes in the concepts of what SVG means and how it interacts with the rest of the web because SVG 1.0 came out, it was finalized in 2001, and the rest of the web has kind of changed a bit since then. So SVG 2.0 is doing a lot of retconning, revising how you think about what SVG means in order to fit better in the rest of the web. So to start that off, we can start with markup. Core of any web page is your markup. And the core idea of SVG 2.0, sorry, of SVG 1.0, the original story was that SVG is XML because back in 1999, 2001, when SVG 1.0 came out, XML was going to take over the world. It was the newest, the coolest SVG was going to come along, you would be able to integrate it with all sorts of different XML languages, XML style sheets, transforms, lots of crazy neat stuff, but as I've already mentioned, XML did not take over the world. So we need 15 years later a slight new perspective. So the new perspective, recognizing that HTML has continued to take over the world, is that SVG is a document model which can be expressed in XML, which still got continuity with everything that exists, or HTML markup. Now, if you already use SVG a lot, you probably already use this without thinking too much. Because if you're using inline SVG code in a .html document, that SVG code isn't being treated as a XML markup, it's being treated as a type of HTML markup in the sense that it's being read by your HTML parser. The SVG 2.0 changes are not so specific to making a new change, it's more tidying up the SVG spec to match the current reality. But an important thing to remember about that, I'm going to move this out of the way, is that if you have a .svg file, that is still an XML file. So what I have here, in this little gift demonstration, two browser tabs, two files with the absolute identical text content. The only difference between these two tabs is that one is a .html file and one is a .svg file. And the .html file has no problem drawing this Euro character. The .svg file gives you the XML yellow screen of death. And that's one error of many in this file, because it's actually a horrible, horrible markup that I stole from a Stack Overflow contest for how few characters can you use to describe this image. But the HTML parser has no problem figuring it out, even all these horrible markup errors. SVG parser, not so much, the XML parser used by the SVG file. So what do you do if you have crappy markup, maybe just hack something together on code pan or just quickly, it works fine in HTML, but you need a .svg file? Well, you use the parser loop. Your browser parser, the HTML parser knows how to turn that awful markup into a good DOM. So you can just take advantage of that. The easiest way to do this is to open it up in Microsoft Edge. And Microsoft Edge, you open it up and you just click on the inline SVG, right click at the context menu, there's a save picture as just like on a canvas or a JPEG. And I'll save it as a perfectly beautiful SVG file that works standalone. It's wonderful. But it's only in Microsoft Edge. And I noticed some of you don't have Windows computers in front of you. So any other browser of the GIF sequence that is being shown there, you open it up in your DevTools, you do copy out or HTML, paste it into your code editor, that's cleaned up all your quoting, it's cleaned up all your tag nesting for you. And the only thing you have to add at the end is your XML namespaces and hopefully your code editor has autocomplete so that you don't actually have to remember what those are. So that's just basic hints. If you're going in the reverse direction, if you're going from an SVG file to HTML file, it's mostly good because that HTML parser is so good at handling weird markup. But the warning is don't do anything weird with XML, especially with XML prefixes, don't ever put prefixes on your SVG or HTML element names. And there are some namespace attributes, always use the standard prefixes, excellent colon href, XML colon lang. If you're using SVG software, like illustrator, it's going to do this anyways, you're good for that point. But if you're using SVG software, you have to worry about a whole bunch of other XML stuff, it might throw in custom namespace stuff, just because it's including all its extra information in case you want to open it up and edit it again. You don't want this if you're cutting and pasting into your HTML file, you want the proper export for web, and then you probably want to throw it through an optimizer as well after that. You'll notice in this one, I actually commented out the actual SVG stuff from this drawing. All the rest there is junk, except for the view box on the SVG is about the only thing there you need. But other than that, you know, if you did copy and pasted the HTML parser would handle it, it's just wouldn't like it. Now that's if you're using a markup file, if you're using scripts, it's a whole different story. If you're using scripts, if you're creating dynamic SVG in the DOM, you always need the namespaces, the DOM still needs namespaces. The HTML parser adds them in for you, but if you're using DOM, you have to create that. You have two options, you either use the namespaced methods or you use a JavaScript library that under its hood uses these namespace methods. So any JavaScript library that's SVG focused will do this, non SVG focused ones won't, and you'll end up with something that looks like SVG markup in your dev tools, because your dev tools don't show you namespaces, but it doesn't draw SVG and you'll be banging your head and trying to figure out what's wrong. And it's, yeah, you've got a whole bunch of HTML elements that just have the names circle path, rect, but they aren't actually SVG circle path and rect. The other option is once again, you can use the parser loop. You can use the inner HTML property of a DOM element. And that if you're in an HTML document, it'll trigger the HTML parser. The only problem with inner HTML is that it was originally only defined on HTML elements. And the new browsers all supported on SVG elements, but depending on your browser support, you can easily trip up with that giving you a undefined or other problems. So what I've got there is creating an HTML div and using its inner HTML property to read the markup. So that's markup and XML versus HTML. The next basic concept when you're talking about web is links. And links in SVG version 1.1 used something called xlink. SVG uses the xlink href attribute to create simple links. Now, since most of you probably don't know much about xlink, it was a very interesting specification, this idea that you could have one consistent way of defining links across many different types of documents. You could have complex multiple relationship links, you could have a single file of links that connected the relationships between two other files that were, you know, video or audio or something that didn't have its own link format. It was really neat and it really went nowhere with the rest of XML. So the only time you bump into xlink these days are all these nasty prefixes in your SVG file. And SVG only ever had these simple links and simple links were basically the kind of links you had in HTML for 25 years now without needing any extra namespaces. So SVG 2 simplifies the story. SVG uses the href attribute to create links. xlink is dead. Q the ding dong, the evil namespace is dead. What does this mean to you? Not much. I'm sorry, but at this point in time, this change does not mean much practically. And this is a tweet came into me just last week. xlink is now deprecated in SVG 2, but if I use without it, it doesn't work in Safari. What should I do? And my answer is still use xlink because you as content creators have to be worried about continuity and the fact that there are lots of browsers out there that haven't immediately updated to the new spec. So for continuity, you still have to use the old one. There are fallback rules in the spec for what happens if you give both attributes, but that would be just introducing redundancy in your code. And why would you want to do that? The only time you actually want to use both of them is if you're doing something like this, which is a code pen I created as a does your browser support SVG href without the xlink prefix. And so it has both attributes with different values. So you get yes or no. Currently, the ones that say yes are all versions of MS edge chrome version 50 plus so that's stable since this past April, Firefox 51 plus, which is currently nightly might have just hit dev edition. But right now, no support, estimated time in Safari and of course, all versions of Internet Explorer and the current stable Firefox. So unless you're using electron apps or something where you just aiming for the latest version of Chrome, keep using that excellent prefix. But you can dream of the day when xlink will really and truly be dead. Next step up for building your website styles. After all, this is a CSS conference. But back when SVG was still created in 2001, as I said, CSS was still kind of new, wasn't sure whether it was just going to be a fad. And the people who wrote the spec decided that they weren't going to require every SVG software out there to be have to implement a CSS parser. So they gave options. They said, SVG styles can be defined with CSS properties, or with equivalent XML attributes. Now, it's been 15 years. CSS keeps getting bigger. They have conferences about it now. And this has been a problem for updating there are lots and lots of new CSS properties, which would mean lots and lots of new attributes. And there are also lots and lots of new CSS for features that don't map to attributes. So there's all these new at rules, new pseudo classes. And how do you represent that in XML attributes? And the other big problem when you're dealing with a progressive enhancement world is that you don't have an easy way of doing fallback in attributes because you can only have one attribute of a given name on any element. So for SVG to the spec has moved all the way on to SVG styles are defined with CSS properties, some of which still have presentation attributes. So I should say CSS is now required in the spec for software that's interpreting SVG. You do not have to use it in your SVG code. If you're worried about your SVG files being processed by little utilities like image magic for creating PNG fallbacks, then you might want to stick with the simple attributes. But moving forward, the idea is to move all the way into CSS. There will be no new presentation attributes for new properties. Using CSS and SVG, you can use anything that the browser supports. The CSS and SVG is just the same as the CSS you use in your HTML file. Not every property applies to SVG, but all the syntax that the CSS parser reads applies. So that means you can use all your usual CSS fallback methods. If you're using something new like CSS variables, you can have a previous declaration and browsers that don't understand variables will just use the previous one. You can do something with an at supports rule if you need to coordinate different styles. And you can build robust applications with lots of fallbacks this way. But one question, you've got all this CSS, where are you going to put it? Really depends what you're doing with your SVG. If your SVG is going to be used as an image, so that you're using it as a background image, or you're using it as something with an HTML, IMG element, then that CSS needs to be in your SVG file. Images do not load additional resources. They don't load additional style sheets. They don't load additional fonts. They don't load additional image files. So SVG has a style element just like HTML. You can put that style element anywhere in your SVG file, and then you can write all this CSS code in there and it'll apply to that image. There'll be no crossover from the main document to the image, but you can do anything you need inside that image file. For other types of using SVG, if you're using object element, then you get an interactive content that can load external style sheets. If you're using inline element, inline SVG, then you can have external style sheets, but you need to watch that your styles now apply to your entire document, your HTML, your SVG, your any other SVGs, which can be a good thing if you've got an icon system that you want to style every little SVG with one line of CSS. It's great. It also means that they inherit styles, so your SVGs can inherit the font size and font color, which you can then use through the current color keyword. Also great, but if you're not paying attention just like any other web page component issue, you can get a style specificity and clashing between different components. So that's how you apply your styles, but what does it mean to style an SVG graphic? Now, as I said, in the original SVG spec, they didn't make CSS required, but it was at a time when CSS was new and especially this idea, this theory that you should separate your styles from your content. That was a big thing in web standards. So SVG wanted to go in that, but SVG is an image format. What style and what's content when you're talking about an image? It's a bit of an arbitrary distinction. But the decision that the spec writers made was that geometry was content and colors and everything else was style. So that makes sense geometric style structure was always defined in the SVG markup. So that makes sense if you have a drawing and this is a great example from SVG Essentials by my co-author David Eisenberg, little drawing of a cat. You take that cat, you take all the styles the same, but you change the geometry. So it's short point of years become long curved ears and it's long whiskers become short wiggers and you no longer have a drawing of a cat, you have a drawing of a rabbit. In contrast, if you take that cat drawing and you keep all the geometry the same, but change the strokes and the colors, you still have a cat, you just have a crazy cat. It's a style change versus the content change. In that context, it makes perfect sense. But not all SVGs are drawings. There are lots of diagrams and charts and in diagrams and charts, the geometry is often symbolic. It's arbitrary and you can change the geometry and the important thing in the geometry is that you've got consistency. Anything that represents the same concept has the same geometry and when you have that sort of thing where you can change it, but you want lots of things to change together, well it would be really nice if you could just slap a class on there and then have a single CSS rule that changed it all. And currently in SVG, you can't do that and so you end up needing some sort of scripting tool that keeps everything organized and up to date. So the SVG2 story, tweaked it a little bit, document structure is defined in SVG markup, geometry is defined by new geometric style properties or their presentation attributes. So we had a perfect opportunity for retcon. SVG already had this concept that style properties could be represented by attributes. So we can say that yes, all those attributes that existed, they're still supported, they're still work, but those attributes are now presentation attributes for style properties that just nobody's known about forever. So the existing story is explained in a new bigger story. Now, what does this mean for you? Well, when it's fully supported, it means you can do lots of things with geometry that you can currently only do with styles, like change it up based on media queries or pseudo classes and animations and transitions with CSS animations. But it hasn't been a perfect transition. It hasn't been a perfect transition because attributes are not directly equivalent to styles. Attributes in markup are always attached to an element and that means they can be defined and explained in context the element styles should be universal. And when the CSS parser reads your CSS styles, it doesn't know what type of elements on. So you have to have the same value always. And there have been many examples in SVG where the attributes were very context sensitive. We had to change it up a little bit for converting to styles. For example, two different elements had attributes called RX and RY, the radius elements. If you attach those attributes to a rectangle, you're setting the corner radius of that rectangle. If you attach those attributes to an ellipse, you're actually setting the size of the ellipse. That point is not a problem, but there was different default behaviors in rectangles. You could only set one of these attributes if you wanted and the other one would automatically match and you get a circular corner. In an ellipse, if you didn't set one of these, the ellipse would be an error and not be drawn. So we have different defaults, different behaviors. In this particular case, it was actually an easy fix. It is going to be a breaking change once it's implemented. It's not implemented now, but the ellipses will borrow the rectangle behavior according to the spec. So you will be able to just set one and the other one will get an auto value, CSS auto and match. In this case, it's a breaking change, but we're only breaking something that was already broken. We're breaking the error condition to create a useful function. That's sort of a spec change where we're okay with that. But there were lots of other cases where it wasn't this simple. For example, we have X and Y attributes all over SVG. In most cases, they're describing a single point. That's going to be the top left corner of a rectangle. But on text elements, X and Y take a whole series of different values to describe the position of every single character in that text. And this is something where the parser has to know what element it is to know whether it's allowed to have many different values. And at this point, the decision has been made to not make a decision. So X and Y for most elements are available or will be available as presentation attributes in your CSS. But on text, they are still regular attributes. This is not a great situation, but it's a compromise. It's where we're at now. The story is not over. But because we have to worry about continuity on the web and preserving things long term, we don't want to jump in and make a bad decision that we're then going to be stuck with forever. So this is where it currently is with SVG2. We've got a variety of geometry properties. We've got some elements, shape elements that you can set those values with CSS. And then we've got other elements, the text elements and graphical effects elements that unfortunately have attributes of the exact same names that aren't tied to CSS. As I said, it's not ideal, but it's dealing with trying to work from what we had and move forward without breaking anything. And that brings us to the other side of geometry in SVG, which is transforms. Now, because it was geometry in the original SVG, it was also originally an attribute-based thing where you had to set in your XML a transform. So, core story, the SVG coordinate system can be manipulated with the transform attribute. Now, Justin talked a lot about transforms, so don't just go into details, but you can make all sorts of cool designs. You can change and manipulate shapes without going in and changing the individual geometry. You can move entire drawings in different positions and angles and whatnot, and it's so wonderful that CSS wanted to get in on the game. And so we have the CSS transforms module, which some of you might be familiar with. And it was going to be an easy retcon for SVG too, just like the other geometry attributes, the transform attribute would become a presentation attribute for the transform property. But unlike the other geometry attributes, there would also be this extension that you could use it in the rest of CSS, not just in SVG. So, we have this revised story. Coordinates, SVG or not, can be manipulated with the transform and the new transform origin properties or with the transform presentation attribute. It was wonderful. Or not. If any of you have actually tried using CSS transforms on SVG elements, you know that the current state is not very wonderful. CSS transforms in SVG are the perfect example of broken continuity web standards. SVG transforms have been around for 15 years. All the browsers have had perfectly interoperable implementations of SVG transforms as long as they've had implementations of SVG at all. But the CSS transforms spec was written by CSS folks thinking about CSS needs and not thinking about continuity with SVG. And this is a problem because SVG layout and therefore SVG transforms were all based on this coordinate system. But CSS doesn't always have a coordinate system. It have boxes which are sometimes floated and sometimes in inline wrapping and sometimes in grids and sometimes in flex. And so CSS transforms were going to be defined relative to the box. And so if you rotated something it wouldn't be rotating around a coordinate system origin. It would be rotating around the center of the box, which is all very useful. But the specs never said how this is going to apply to SVG. So different browsers took different solutions. Firefox just maintained continuity and their application of CSS transforms to SVG matched the SVG transforms that have already been implemented. Blankin Webkit went for trying to be as close and SVG as they were in the CSS and used individual boxes around the shapes. And so far Microsoft has dealt with the issue by not dealing with the issue and not applying CSS transforms to SVG at all. There is hope. There has been something in the draft spec for about a year now and there was an agreement by the CSS working group last week to get this and the rest of the 2D CSS transforms in a stable spec published as soon as possible so that hopefully the browsers will implement it as soon as possible. 3D transforms have been pushed off because they've got a whole other set of bugs. But the important thing for SVG is something called transform box which is going to be a new property. And to set explain what that is, imagine a very simple SVG. I've got an SVG element and one polygon in it and the only important other thing there is I've got this view box on the SVG which as other people have mentioned sets up your coordinate system and I'm setting up my coordinate system so it's 70 units wide, 70 units high, but it's offset by 35 units so that my center of my coordinate system is actually, my origin of my coordinate system is going to be in the center of my SVG which I am representing in these images by the dashed lines being your x and y axis. So with transform box this new property you're going to have two options. You can say transform box view box, view box referring to that SVG view box attribute. So now all your transforms are relative to that origin in the view box and if you have any percentages they're relative to the width and the height of that view box SVG area and this is completely backwards compatible with SVG transforms. The other option is to say transform box fill box and it will create a box around the fill of the SVG is the name for the basic core paint of an SVG shape so the fill box is basically the geometry box not including the stroke outline and you'll use that box as your reference box. The 0,0 point will be the top left corner of that box but you could easily change your transform origin back to the 50% default that it is for CSS boxes and so by changing two properties if you like the CSS mode of transforming and that makes sense to you you'll be able to do it versus if you want this SVG mode you'll be able to do that and it will be wonderful when it gets in browsers. It's not in browsers yet. So the question is what do you do for now? Here's a final story, multiple edits of where we want to be. That's where we want to be with transform transform origin and transform box in browsers but it's not there yet. So what are you doing if you want to transform SVG elements for now? For most things keep on using the attribute. As I said all the browsers have interoperable implementations of the transform attribute. If you're using CSS transforms make sure it's a progressive enhancement and make sure you don't use any percentages because that's currently the main disgruntlement between the Chrome and Firefox implementations. But if you are using the transform attribute and you use to the CSS transform property be aware there are other important differences. The SVG old syntax does not use units. It always use numbers that are equivalent to either degrees or pixels depending on the context and there are also lots of these new shorthand functions in CSS which don't have equivalent in the old syntax. So you're doing this for fall back. You want maximum support. You've got to use the old syntax. These changes were a good retcon. The idea is that future browsers will continue to support the old syntax in the attribute. Not in the style property but in the attribute you'll be able to continue to use the old one. So for now you should use the old one so that the old browsers can support it. The other way you be using CSS transforms on SVG is if you want to as I said add in extra effects like maybe 3D transforms which didn't exist in the old SVG. So you can create a cool layer with 3D transforms and then you can make a lot of adjustments to this to do with all the bugs of 3D transforms which are bad in all of CSS but especially bad when applied to SVG. So I'm actually fading something to zero opacity at the back there because otherwise things were getting painted in the wrong order and it was kind of horrible. But it worked. Little adjustment, fun little effect. We've got the team web. Everybody moving. But if you look at that in Microsoft Edge I've got a 2D layout and Edge doesn't apply the CSS transforms but it still applies that transform attribute. The other browsers the transform attribute just gets overridden by the CSS so the fallback doesn't hurt them at all and the only complication is that I've still got that opacity animation coming through because the you can't use the at supports rule to cancel out your 3D transforms if they're not supported because Edge does support 3D transforms on other elements just not an SVG elements. So it goes back to the bit about the universal parser. The CSS parser is what does the at supports rules and it thinks that's valid because it's valid on some elements and then it just doesn't get used in actual drawing. But in this case I think that's an acceptable fallback that somebody who just saw this would totally think that that was an intentional design choice and not a side effect of a hack that was created for a completely different layout and just spilled over into this layout. It's not perfect but if you're willing to accept the website does not have to look identical in every browser theory then you can make it work. That's about all I have time for today. There is much much more that I would have liked to tell you all about. I'm going to try and turn these into a series of articles about other new features and which you can and can't use yet but otherwise you can find me or tweet me or email me if you have specific questions and that's all about me and thanks for your time. You can bring that mic over and then I can just yeah much easier. So much exciting stuff in SVG too. So you've had like a so exciting right. You haven't even talked about mesh gradients yet. What? Mesh gradients. They're all other talk right. So you've kind of had a sneak peek into this for a long long time. Like how are you like holding your tongue and biting all this information for so long. Oh goodness we haven't been holding your tongue. Definitely if you care about this please look into the specs. Start playing around with the experimental implementations like I should have mentioned the geometry properties. There's experimental implementations in Chrome and WebKit. You can play around with them. They're a little buggy and not to the current spec but if you're careful with your fallbacks you can do interesting things with creating alternate media query layer or something like that. So yeah play around them and also for the things that aren't implemented that look into them talk about them tell the browsers you want them to implement them because that's the only way we're moving forward. So how do we tell the browsers that we want to implement them or that like we found a bug. There are all the browsers have bug reports now. So the different bug trackers of the open source things you know most of them have feature request bugs for all these new features that you can upvote and Edge has a separate feature request system that's different from their bug tracker but they're both open and you can vote and encourage things and also you know just be vocal on social media Twitter and whatever there's lots of browser dev well people that you can harass about this is really important and I would totally use your browser all the time if it could make really awesome 3D animations with performance or rapping text in SVG is another thing coming and so yeah it's cool to get the word out nag them so question from the audience CSS properties seem like a recipe for class name complex if you export and minify your SVG assets how is SVG to going to avoid this or is this not even a problem. CSS properties oh if you've got like multiple SVGs and then you're combining them all into one giant file yes that is something that you're going to have to factor in your build tool whether you want all those icons to be styled consistently or want individual control then yeah you're going to need a naming system and possibly something in your build tool that will add extra prefixes to classes so that you can have you need honestly probably the best situation where we have something that takes every class and gives it both as the common class name and as an icon prefixed one so you can then target both one in your CSS. Cool that's going to be a good thing so what else besides mass gradients in your talk is super exciting to you or other piece that you can get to an SVG to I would have liked to talk about the SVG and open type fonts there's some cool demos out there and just as of August there they've been supported in Firefox for a couple years as of August they're now supported in Microsoft Edge as well they're kind of the replacement for the old SVG fonts which are completely dead because they had many problems and browsers that did support them never supported the cool features and support has been removed but SVG and open type kind of combines the best of the SVG fonts with the best of all other font formats that are currently in active use and sort of not a retcon a complete do-over learning from the past mistakes. Cool nice stuff well I imagine you're still going to be around for most of the day right I'll be around for another hour or so. All right cool well if anyone has more questions on SVG you know where to find Amelia let's give her a huge round of applause.