The following is a guest post by Rob Levin. Rob is a Senior UI/UX Developer at Mavenlink, and coauthor of the Unicorn UI CSS Button Library. Their 2.0 release is using an SVG icon system, and here he shares some issues he’s ran into along the way, and how you can watch out for them and fix them. Plus, Rob provides a full system you can use, including a working build process and demo.
You’ve read up on how inline SVG’s are better than font icons and are ready to take the plunge. You call a meeting with your team to discuss moving over to inline SVG icons. Your boss is skeptical. He looks you in the eyes and says “So, can you guarantee this isn’t going to come back and bite us in the butt?”. You hesitate a bit, but somehow conjure up the confidence to confirm, “Yes, this is definitely the direction we need to go!”
This was me just a couple months ago, and here are some “gotchas” I ran in to with corresponding workarounds. I’ll start by examining the workarounds one by one, and then provide a working example at the end.
Please note that this is not a persuasive article on why you should use inline SVG. For that, you should read this popular CSS-Tricks article that points out the advantages of inline svg over icon fonts.
Gotcha One: Missing the Target
In order to achieve caching using an external SVG file (you seriously don’t want to dump ~1.5kb * 50 icons on your page in a non-cacheable way right?!), you need to include the svg4everybody library on your page. Essentially, this shiv will use UA sniffing to detect if you’re running a “problemattic version” of IE or Android that doesn’t properly cache external definitions files, and, if so, removes all svg use elements, and replaces them with embedded elements containing the corresponding SVG definition data pulled in via ajax. At the end of the day, we just care about the fact that our original SVG that might have looked like:
<svg viewBox="0 0 16 16">
<use xlink:href="/path/to/svgdef.svg#your-icon" … ></use>
</svg>Will get replaced with an embedded element that looks something like this:
<svg viewBox="0 0 16 16">
<path> ... </path>
</svg>CSS: Hitting the Target
Depending on the source SVG, you might end up with a hierarchy looking like: svg path (as above), or, it might be svg g, or possibly a combination of grouped and path descendants–but do remember, you’ll need your CSS to target the “pollyfilled” cases–this means you’re CSS rules should absolutely never target the svg > use element directly… it will get completely removed in IE!
JavaScript: Hitting the Target
The same idea holds true for any JavaScript manipulations on the SVG clone itself. For example, we may want to swap icons on a hover and–one technique we may choose–is to alter the xlink:href attribute with JavaScript when such an event fires. Since, in this article, we’ve elected to use an external file with the above described shim, we can’t reliably use that technique (again, the use element gets replaced in IE). My recommendation is to just hide/show via CSS classes (Technique #1 described in Swapping Out SVG Icons article), and be sure to target the SVG clone itself.
If we’re directly dropping in the inline SVG definition at the top of our page (ex. right after the opening <body> tag), we won’t have this concern and using the technique of manipulating the xlink:href attribute is fine.
Selector Examples
Just to make the above points crystal clear, here’s a CSS selector that would work in browsers that fully support external SVG definitions but fails when svg4everybody pollyfills IE:
.my-svg use {
fill: red;
}It turns out there’s no real need or gain to target use, so just change that to the following to work for all cases:
.my-svg {
fill: red;
}While we’re talking about selectors, we should take this opportunity to point out you won’t be able to “reach in” to original SVG definition with something like:
svg.parent path.child { /* won't work! */ }The same would apply to trying to style anything in the def itself via the cloned instance be it a shape, path, group, etc. It may be obvious, but this is only an issue, here, because we’re using the use xlink:href strategy.
Gotcha Two: Working With A Designer
If your icons generally use only one color, applying CSS styling to a cloned instance in “one sweep” is trivial with: fill: <your-color>. For such cases, the designer on the project will need to be mindful to create the vector art applying either: only black fills with transparent strokes, or, only path data (transparent fills and strokes). You’ll still be able to apply strokes via CSS if you need to.
To understand why this is, we first need to understand how our vector application exports SVG.
I use Adobe Illustrator, but if you’re using another vector program like Inkscape or Sketch, etc., you’ll want to refer to that software’s documentation to see if their behavior matches what follows. Worse case, you can just export the files in the various ways I describe in the following and test out what your application’s generated SVG looks like.
Illustrator SVG Export Behavior
At time of writing, the latest version of Illustrator CC exports to SVG as follows:
- If you don’t define a fill or stroke, or, you define only a fill, but that fill is black (completely black as in
#000), the exported SVG paths and shapes will not contain a fill or stroke attribute:
<path ... positional information ... >
<rect ... positional information ... >- If you define a non-black fill, or, if you define a stroke (of any color including black), the exported SVG’s corresponding paths and shapes will contain stroke and/or fill attributes like:
<path stroke="#000000" ... >
<rect fill="fabdad" ... >These presentational attributes will always be overridable by CSS should you apply a style to the SVG symbol, path, shape, etc., directly. The caveats involved with applying CSS to a cloned instance (not directly), are described next.
Exporting Black Fill On / Stroke Transparent
If your source SVG was exported with black fills only (no strokes), or paths only, then you have a lot of flexibility, since you’ll be able to apply a stroke or fill via the CSS.
In this first example (note I’m using SCSS syntax), we apply a CSS fill and stroke to the cloned instance:
.filled-instance {
stroke: #cc8ac1;
stroke-width: 5px;
fill: lighten(#cc8ac1, 20%);
}You’ll also be able to achieve an outlined effect by simply turning off the fill and applying a stroke via CSS:
.filled-instance-off {
stroke: #d08aaf;
stroke-width: 5px;
fill: transparent;
}The reason that this works so beautifully, is that our SVG definition doesn’t have any fill or stroke attributes defined, and thus our CSS gets applied and all is well.
Exporting Stroke On / Fill Transparent
So the bad news here, is that you cannot apply a style to the stroke on the cloned instance (remember, our cloned instance, in this example, in turn, points to an SVG def that we created with “stroke only”). We can’t apply a fill to our cloned instance either, since our SVG shapes now have fill="none" on them and that will take precedence):
.stroked-instance {
stroke: green; /* nothing happens */
fill: red; /* nothing happens */
}It’s similar to HTML/CSS, like:
<div id="very-strong">
<span>still green.</span>
</div>#very-strong { color: red; }
span { color: green; } /* I'm the actual element, so I win. */Some Workarounds
You probably should just avoid this situation altogether by exporting black fills with transparent strokes, or just paths, but, if you, for some reason, do still need to have your styles take affect, you’ll instead have to style the SVG symbol directly with something like:
symbol#completed-copy-stroked [stroke] {
stroke: #dd6435;
stroke-width: 5px;
}Note that the symbol part of the selector above is unnecessary but used here for clarity as to what element we’re targetting
Again, this isn’t really ideal if you’re using an inline SVG with cloned instances approach, since we’d prefer to apply styles to our clone instances where possible.
Another technique you can always use, is to just add classes within the source SVG and apply CSS to those directly. These styles will be global which may or may not be a problem–you’ll have to decide that for your case. This technique works regardless of how you exported the SVG. Because you’re hand adding a CSS class, it’s there for you to hook into (albeit directly–we’re targetting the SVG definition’s sub-element directly and not styling through a cloned instance):
.ibestrokin {
stroke: magenta;
stroke-width: 5px;
}
.istrokeittotheeast {
stroke: green;
stroke-width: 7px;
}Maybe I’m showing my age, but I just can’t help but think of Clarence Carter with all this talk of “strokin”.
To my mind, only being able to style the SVG directly (and not the cloned instance), is less than ideal. Therefore, my recommendation would be to avoid exporting strokes altogether in cases where you’re going to be using inline SVG and cloned instances. If you already have artwork that has strokes defined, you can look in to ways to convert those to paths via something like Outline Stroke before you export.
See the Pen Inline SVG Fill and Stroke by Rob Levin (@roblevin) on CodePen.
Post Processing
Another consideration, is If you’re using a post-processing library such as grunt-svgstore to cleanup fills and strokes. In this case, the generated SVG may not have explicit fill or stroke attributes at all, and only path information will be left in the resultant definition file. For this case, you definitely want to convert any strokes to paths or risk losing the corresponding visible lines altogether. Alternatively, don’t ask for strokes to be removed by the post-processor (but face some of the issues I discussed earlier). Bottom line, if you’re artwork really must have a stroke, figure you’ll have to target the SVG directly.
Conclusions
So I guess the takeaway is that you’ll need to make a decision with the designer, as to whether you want all fills and strokes to be completely controlled via CSS–in which case you should just use paths with transparent fills and strokes (or black fills if you’d like them kept around for reference)–or, does it make more sense to start with sensible defaults, and then use CSS to override these as needed. If you’re using inline SVG and prefer to style to cloned instances (not directly to the SVG), my recommendation is to just use paths.
Gotcha Three: Achieving Color Variation
One of the purported benefits of using SVG, in general, is the flexible style control we get since we can apply CSS to an SVG’s path, shape, etc. However, using the use xlink:href mechanism results in a non-exposed cloned DOM tree, for which our fill or stroke styles will apply to the referenced SVG globally. The implications of this, is that all cloned instances will share the same fill color.
Fortunately, there’s a trick we can use to at least get one unique color per instance. If we go in to the SVG definition itself, we can apply fill=“currentColor” to a shape or path of our choosing. What does that do? Well, the long supported CSS value currentColor, specifies that color will be inherited. This means that we can define a font color higher up in the tree (for example on the cloned instances themselves), and the fill for that path or shape will inherit the color. I’m not sure who first thought of this, but I’ll give credit to where I saw it first: Jenna Smith’s tweet.
Implementation
We start with our base fill which might look something like:
.icon-primary {
fill: #ccc;
color: #3bafda;
}Those classes would get dropped on the non-exposed svg clone instance:
<svg class="icon-primary"> ...Now here’s where the magic starts to happen–our fill defines the icon’s general fill color (in this case #cc), but now our font color defines the inherited accent color we defined as described above like:
<path fill="currentColor" ... />
currentColor to achieve an accent color on an SVG pathIf you’re using grunt-svgstore in your build process (the example at the end of this article does), you’ll likely configure it to remove unwanted cruft via the cleanup property, and this library now preserves fill attributes with the value currentColor … so you don’t have to worry about clobbering the custom attribute defined above.
I’ve created a Sass mixin (purposely compatible down to 3.2) for doing this:
@mixin svgColors($fill: false, $color: false, $patchCurrentColorForIE: false) {
@if $fill {
fill: $fill;
}
@if $color {
color: $color;
}
}And I call it with something like:
.icon-primary {
@include svgColors($neutralColor, $primaryColor, true);
}If you’re wondering about the $patchCurrentColorForIE parameter, I have that there for the icons that won’t require multiple colors, and thus don’t need the shim applied.
Other Color Variation Techniques
In addition to using the currentColor technique listed above, you can also use a preserve-- attribute feature now available in grunt-svgstore. How it works, is if you use preserve-- as a prefix to any valid attribute in the source SVG, that attribute will be forced to remain in the resulting SVG (with the preserve-- prefix removed). For example, preserve--stroke would result in just stroke in the output SVG definition.
Another technique to consider, if you’re wondering how to achieve color variation–in this case for a background-image–is to take the approach of using a data-uri of an SVG, but first do a search and replace on the fill value as described here. However, that approach is a bit out of scope and off-topic for this article, since it means using a non-cacheable data-uri going against our primary goal to employ a cacheable external SVG definitions file.
Gotcha Four: jQuery Throws Error
If you’ve included jQuery on your page, clicking directly on a rendered svg use element will likely result in jQuery throwing an error that’s documented in their bug tracker. It’s actually a bit tricky to reproduce this bug since you’ll likely have a containing block element that serves as an anchor or button–and that element will have the larger hit area–but, again, it happens if you click directly on the icon itself. Here’s the preferred workaround:
svg { pointer-events: none; }Since pointer-events are inherited, this will cause any of the SVG “sub-elements” to also not respond to pointer-events. Once you’ve set this up, you should be mindful to ensure that any event handling (like a JavaScript click handler for example), is handled by an ancestor element and not the non-exposed SVG clone itself–a button or anchor are obvious examples of wrapper elements that would need to do the event handling in this case.
If you do intend to handle mouse or pointer events on the SVG itself for animations or the like, you should probably consider just using an img or a CSS background tag for that particular SVG; doing so will make this a non-issue.
Gotcha Five: GitHub Diffs
One concern we had was that the SVG diffs are pretty archaic to a potential code reviewer. Chris Coyier pointed out to me that GitHub has recently deployed a sweet svg viewing feature which allows you to toggle a view of the blob. Very handy.
Additionally, a team-wide policy to keep such SVG work in a separate commits (so it doesn’t muddy more meaningful code changes) is probably the pragmatic choice here.
A Working Example
I’ve set up a “toy example” that you’ll hopefully find helpful. It implements inline SVG using a Grunt workflow, and relies on a cacheable external SVG definitions file. Note that this example does require IE9 and above.
If you’re not yet ready to set this up, here’s a demo page of what we’ll be deploying.
If you need to support IE8 and below, you can fallback to a png image of the same name as your SVG (but with the .png extension). Setting this up is described in the instructions for the svg4everybody library we’re already using so start there.
To run the example you’ll need the following installed:
Run the following commands in your terminal to fetch the example and deploy it locally:
Depending on how your system is set up, you may need to use sudo before the two npm install commands below
# Install the Buttons example and set up npm dependencies
git clone -b svg-inline-experiments --single-branch https://github.com/unicorn-ui/Buttons.git Buttons && cd Buttons && npm install
# Install the SVG specific dependencies and run example
pushd svg-builder && npm install && grunt && popd && grunt devWith these commands we:
- Clone the repository grabbing just the relevant
svg-inline-experimentsbranch - Install Buttons node dependencies
- Install SVG builder node dependencies
- Run our Grunt development workflow which builds the example’s inline SVG definitions and also build the example page
Depending on your set up, the last step should result in opening up the following page in your system’s default browser (if not, visit http://localhost:8000 manually):
If you’d like to reverse engineer this set up in order to inform your own project’s setup, the files you’ll want to reference are:
styleguide/includes/svg.htmlshows the markup used to create SVG instancesstyleguide/scss/module/_svgs.scssshows the CSS styling applied to our SVG iconssvg-builder/Gruntfile.jsa working Grunt configuration customized specifically for inline SVGstyleguide/pages/index.htmlthe only real thing you need to take note of in this file is that we includesvg4everybody.min.js
Conclusions
Having successfully addressed the above challenges, I’d assert that teams building modern web applications should definitely consider using inline SVG right now. Unicorn-UI is gearing up to implement an “interactive playground” for our recently released Buttons 2.0 Beta, and, for obvious reasons, we’ll definitely be utilizing inline SVG for that project… perhaps you should consider it for your next project too.
As a follow up for advanced use of SVGs you definitely need to watch this talk! It goes deep into browser support and even more quirks you want to avoid.
Thanks Nico…I’ll check it out after work.
If the SVG code exported from your graphics program has presentation attributes (stroke/fill colors specified as attributes), you can force the browser to ignore them and use the values you specify in your stylesheet for the individual icons with one simple rule:
[Note, this rule should be in the same file as your icon definitions, so if you’re using external files but AJAX-ing the graphics into your main file when external references aren’t supported, you’ll need to add the rule to both your external file and your main stylesheet.]
The
*selector may be bottom of the totem pole as far as CSS selector specificity goes, but it still overrides presentation attributes — and both Illustrator and Inkscape use presentation attributes for color information.Now you can do things like
The graphics within each icon will inherit the styles.
Of course, this only works for simple, one-color icons. If you want more nuanced control, you’ll need to get into the code and get to know the SVG style cascade rules.
Amelia, thanks for sharing this. This is an interesting approach and I’m definitely interested in experimenting with to better understand how it will work in practice.
I agree that the use of
*is unfortunate, as is the extra presentational data in the SVG def (if it’s working against the intended goal than I see it as extra weight and maybe worth just not being exported at all). So my gut is that just exporting without the presentational attributes altogether is still a winner. I’d love to hear if you agree with that statement?Definitely. But sometimes it’s easier to over-ride than to dig in and change the code. Or perhaps in some use cases you want to be able to define default colors in your icon definitions, but still have the option of changing them depending on the use case. (pun not intended…)
Hi Amelia, does that definitely work for stroke (colour)? I’ve got it working with fill but not stroke.
Never mind; I’ve found the issue. I was using
[role=img]as the selector to set the inherits. Although this worked for the fill, it didn’t for the stroke. Which seems strange.Thanks very much for the tip.
Oh my, sorry for the triple post here.
I didn’t realise that the symbol I was setting fill on didn’t have its fill set in the SVG. So
[role=img](andsvg) don’t override the SVG’s presentational attributes in my case. (Symbols and use/xlink with an external CSS file.)For number #3 there, I think that
<use>elements can target the shadow DOM with::shadowor/deep/selectors, but browser consistency is spotty.Ian, yeah good ole’ cross browsers huh; interesting tip all the same (especially for debugging purposes). Care to share a pen or more explicit example markdown comment here?
Hi Rob,
The selectors I mentioned are a part of the draft published back in April of this year, being so new they’re not really supported all that well – but Blink matches the rules despite a bug that prevents the CSS from calculating correctly. You can see a pen here:
http://codepen.io/TigerC10/pen/LEYGoo
Ian, thanks for that link to the pen. Very cool stuff esp. for debugging. Just having those chrome flags turned on is helpful since you get the whole #shadow-root visibility in to “host” which is super convenient.
What DevTool do you use in browser? Is it Safari build-in? Never saw it.
Yeah, I usually use Chrome for devtools but I have lots of ugly plugins and what not. So I just used Safari to keep the screenshots a bit cleaner.
There is a method that you missed that I have found to be very effective: injecting an external SVG into your HTML inline.
After the page loads, I use jQuery AJAX to inject the SVG content directly into my HTML. This results in having a cacheable SVG file that browsers cache, but still gives you fine control over the CSS of the SVG elements AND allows you to reference SVG elements using xlink href.
I use this method and it works great. Very simple and effective.
The biggest downside of using an external SVG is that you can’t finely control the CSS colors of the individual SVG elements.
Thanks for sharing Jake! When you mention: “results in having a cacheable SVG file” – do you mean the browser will cache the javascript file that’s doing the injecting?
Are you using JavaScript to change colors before the injection adding CSS inline? Also, are you styling the SVG defs directly? That’s cool, but again, I’ve tried to prefer not styling “globally” if possible favoring styling to the cloned instance where possible.
I’d be interested in if this might allows you to host the JS file cross origin but still inject the SVG. In my testing, the external SVG file does need to be on same domain. So that might be a win with this technique. If you already have a pen or test you can share I’d like to take a look.
@Rob
Can you give more explanation of this bug? I haven’t been able to replicate it.
If it is an issue, I don’t see anything wrong with your suggestion of using the CSS to set the style to the value of the presentation attribute, but I’ve never come across a problem with
currentColor.The above works as expected in IE11 on Win7, and in IE10 compatibility mode (couldn’t test IE9 mode within CodePen). What am I missing from the way you were styling your graphics?
Amelia, I think there’s a confusion on the fact that this issue is specifically for using inline SVG, but with an external file, and using the svg4everybody polyfill (although I’m not sure that the pollyfill is required to repro this case…just how my set up was). I’m at work so I’m going to try to come back to this when I have more time. I can say that (if you’d like to replicate the issue), it might be better to try testing with something similar to the last example with the
git clonedirections. I took advantage of the already presentable Buttons showcase to pull together the example, so, unfortunately, it’s not a simple “bare-bones” setup, but you should be able to put that together given the information I provide at the end of this article. I might just do this myself if/when I get some more time and throw it up on github.It’s definitely challenging to discuss this topic with the variations between styling SVG’s directly, using external files, post processing, etc. Maybe I need some more visuals to bring these variations home.
Amelia, I’ve went back and tested this with both my demo code and a simpler test case, and it looks like I made a mistake there. My sense is that I had some faulty CSS at the time I saw the false negative. In any event, I’ve tested the updated version without the IE hacks mentioned, in IE9-11 and also confirmed latest FF/Safari/Chrome and it works fine. So I’ve updated the Gotcha Three: Achieving Color Variation section and sent it in, so hopefully the article will get updated later today. Thanks for pointing this out.
Thanks for checking it out. And I’m glad to know that I don’t have one more SVG bug to remember about!
I used a slightly different technique on my company’s client list containing two color logos, where the colors can be dynamically changed depending on the website’s current “blend”.
I combine the SVG logos dynamically as
symbols into one file using WordPress , and the rootsvgtag has a class of.client-logos( view source here ). The logos are then included on the page withuseinside of aspanwith the class of.client__logo.The individual
paths do not havefillattributes, but haveclass="light"orclass="dark". The fill is then set in CSS by targeting.client-logos(thesvgelement’s class, for Firefox and IE) and.client__logo(the containing element’s class, for Chrome/Webkit), like so:This method worked flawlessly in IE9+ (using svg4Everybody for
usesupport). Colors could even be changed dynamically with hover states, etc. In theory, you could add as many colors as you want using classes in the SVG.Hey Shaw thanks for sharing. I think that’s similar to what I mentioned about targeting the SVG directly. One thing I’d wonder about is whether you’re dynamically generated WP file is getting cached or not. Another thing (and many use cases don’t require this) is whether you have the need to have two instances pointing at the same def, but requiring different accent colors. I believe you’re strategy is more the global approach (which is fine but something to consider).
One thing that might be more convenient with something like svg4everybody, or even another shim, might be to just plop in the SVG definition at the body for IE et al cases. Embedding each one isn’t probably any better then just pushing the def on to the page; then we could still target
usewithout the annoyance. Guess this is a bit off topic from your comment but I thought of it since you mentioned svg4everybody.Thanks for the response. The color change via CSS is due to the “blend” feature where the entire skin of the site changes. The user receives a new CSS file, but doesn’t necessarily get new content for the pages, meaning the
usereferences would be the same. Being able to control the style of those SVG Logos via the CSS was by far the easiest approach so I didn’t have to create variations within the SVG file itself for an unknown number of blends, or try to swap the icon references out with Javascript.Regarding caching of the dynamic SVG, in Chrome’s network tools, the response header has
Cache-Control:max-age=2592000, which I have set in the .htaccess for all images. However, other images and CSS/JS all show a status of304 Not Modified, whereas this SVG shows200 OK. Any ideas on what might be happening there?Regarding why it’s not caching, yeah, that’s why I mentioned “I’d wonder about is whether you’re dynamically generated WP file is getting cached or not”, since (without looking in more detail at your implementation) it would seem equivalent to as if you’d dropped in the SVG def “as content”; you’re just doing this dynamically (which is kind of cool and possibly a requirement for the effect you’re trying to pull off). I guess I’d be pragmatic about it. What’s the total increase in size? Are you trying to support folks on mobile viewing on the morning train, or, is it more of a “show off” site? Again, I’m not sure just how dynamic your implementation needs to be, and I’ve just worked with this for setting up fairly static icon sets, but I could imagine something like the following:
say you had three “themes” that a user could choose red, green, blue (for simplicity)
you’re dynamic code determines what they’ve asked for in the past (i dunno how, maybe a cookie or db retrieval, etc.)
you pull in the corresponding external SVG def file which is then cacheable esp. for that user if they keep that theme on subsequent visits
I apologize if this is totally off the mark for what you’re trying to achieve, I’m just brainstorming since the general use case of dynamic external cacheable files does seem like an interesting problem to solve for.
If you do get find a solution please do post back a link to an gist, pen, etc. Thanks Shaw!
After re-reading my response and your initial post, I just want to mention that the main difference in what I’m suggesting is that, while your file is dynamically generated, I’m wondering if it would make the difference to have “preconfigured static files” and the dynamic part would be just choosing between them. It totally might not support your use case I dunno, but my thought was that those files, being static, could then be cacheable.
I may have solved the dynamic caching issue by setting up a redirect in WordPress pointing
clients.svgto the dynamic SVG page. By having the actual .svg extension, Chrome seems to be caching it correctly and getting proper304 Not Modifiedresponses.This is definitely a “show off” site since we’re a creative agency, but I tried to make the experience as light as possible on mobile (though it’s still pretty heavy overall), limiting the amount of images and files where possible.
I think for this use case, setting the colors in CSS makes the most sense. The user gets a randomized theme whenever they click the “blend” button, but the content of the site itself doesn’t necessarily change so the SVG references on the page are the same (
<use xlink:href="logo-att">).Since they already get a new CSS file that contains most of the new theme’s look, the color can just be set there, no need to generate another SVG file. Much easier for maintenance and for adding new themes.
The dynamic SVG wasn’t necessarily a requirement, but I wanted to make it easy to add new logos in the future, and now it can be done within WordPress without having to mess around with awkward grunt processes to concatenate SVG files or trying to manually maintain the SVG file.
Thanks for the back and forth, it’s helped me dig a little deeper into the method. If I can improve this dynamic SVG method a bit, it could be a useful WordPress plugin to generate SVG icons.
I found couple of gotcha with inline svg and Angular.
Angular views don’t understand xlink:href out of the box. You have to create a new module to make it understand. This is a solvable.
When you put inline svg within a ng-repeat to show a list of icons, the icons don’t render on page load. The icons appear after certain events (can’t remember off the top of my head) . I could not find solution to this. I will create a pen to illustrate this if I get some time.
Thanks for the article.
Mouly, I spent two weeks with Angular once upon a time and never went much further so I’m not likely the right person to steer you in the right direction sorry (maybe another css-trick reader will though!). Do create the pen if you get some time and post back. Thanks Mouly!
While working on the Rushmore website and using React.js, I realised something interesting, that makes life much simpler.
If you’re gonna use React, and use javascript to render everything anyway, (it IS possible to render on the server-side with Node.js), then the use elements don’t really help. The best approach in such a case is to always inject inline svg.
One big benefit, is that it makes writing CSS targeting the svg and it’s individual parts much, much easier. With use tags, targeting small parts of an SVG becomes very unreliable.
Secondly, if you use something like browserify or web pack, you can inline your entire SVG file as a string in your js bundle, so it can further reduce HTTP request, while also being cacheable. Obviously, if you want, you can still rely on AJAX calls instead.
Sam Ellis wrote in with an interesting SVG gotcha: