Technical Considerations when Using SVG

I finally was given a project that gave me the requirements allowing me to use SVG. At first, I was excited! This is the first professional project I have been able to use SVG with, and I was itching to try it out. But, I tell ya, it’s been ‘interesting’ so far. When I first thought about using SVG in this project, I figured, hey, just use SVG for the icons in the site, instead of a sprite, easy! Well, not exactly THAT easy. There are some things to consider, OTHER than browser and device requirements.

 

Questions, questions!

 

Some of the other considerations that came up:

  • How does this affect SEO?
  • How does this affect accessibility?
  • How does this affect our workflow?

In terms of team responsibilities, who should do what?

  • What would be the responsibility of our creative team?
  • How about our frontend devs?
  • How about our UX team?

Along the way, during implementation, other thoughts came up, mainly to do with technical implementation. Things like:

  • Should we use a SVG sprite, in the traditional sense?
  • Should we group SVG code into one external file?
  • Should we instead use single SVG files?
  • Or should we use inline SVG tags?

 

Google to the rescue?

 

In trying NOT to recreate the wheel, off to google I went. Considering SVG has been around since around 2001, I figured there would be lots of others who have had these same questions, and maybe some answers also.

Let’s go through my questions above, one at a time, and see what I have found so far.

  • How does this affect SEO? How does this affect accessibility?

In researching SEO, most of what I found was positive, IF you use the tag right. I found similar talk when researching about accessibility. There are many additional tags and attributes you can add to allow web crawlers and screen readers to better understand your SVG tags. Here are a few of the more important ones:

  • Title Tag (Like the alt text in an IMG tag)
  • Text Tag
  • Desc Tag
  • Role attribute (What type of SVG is this? I am using mostly the img role)
  • How does this affect our workflow?

In terms of my workplace’s current workflow, this is a bit of a departure. Prior to this project, most of our ecommerce projects had to support IE8, which made using SVG tags pretty much not an option. Usually, like many companies supporting older browsers, we went tried and true png sprites. Since we are comfortable with this approach, it makes the whole process faster. Adding any new use of a technology is going to slow the process down some, but I’m hoping this will be a step forward.

  • What would be the responsibility of our creative team?

I opted to have the creative team support the SVG implementation by creating the initial SVG files, but exporting them from illustrating and storing them on a shared drive, so that the frontend dev team can access the individual files.

  • How about our frontend devs?

Frontend devs will either use a single SVG tag implementation, or combine code to create a group of sprites. They will also add the additional tags and role attribute, to allow SEO friendly and accessible SVG tags.

  • How about our UX team?

Our UX team supported by assisting with with the SEO and accessibility research, and making recommendations of what tags and attributes to use.

 

MORE Technical Considerations…

 

These last four issues are technical concerns which may require some more intensive research, as there are pros and cons to each. Unfortunately there is not a single ‘one size fits all’ here:

 

  • Should we use a SVG sprite, in the traditional sense, using background image to add icons to the page?

This sounded, at first, to be an ideal solution, basically having one large SVG ‘image’, and use it like a traditional sprite, locating the desired image within the sprite, but, in thinking about the technical implementation, especially on a responsive site, it starts to get fuzzy.

Cons: You would have to do some calculating to decide on the size of the initial sprite image, and then, from there, also calculate the location of each icon in the sprite, for any size responsive view. Maybe this is an ideal solution when given the time to hash out these details, but when project deadlines are fast approaching, maybe not such an ideal solution.

Pros: one external, modular file, one http call, sounds like a sprite (conceptually easy to explain to other frontend coders, and easy to understand), and now also scalable and vector!

  • Should we group SVG code into one external file?

This Is done a little different then the sprite, in that you are just grouping the code of multiple SVGs into one file, but having separate graphics in the file. So, there would be multiple SVG paths, with unique IDs, so you ‘access’ them separately.

Cons: Again this sounded like the ideal solution, after the first solution above, but with this one, the entire code for the entire group of icons is loaded. To show only the one you want, you hide all the icons except the one you want to show, using CSS, so a lot of additional code is added to the DOM. Depending on the number of icons, this could happen multiple times. Also, the concept and technical implementation is harder to explain on this one.

Pros: again, one external, modular file, one http call, only scalable and vector; you also don’t have to figure out icon location, just call using an ID

  • Should we instead use single SVG files?

This is just what it sounds like, each SVG icon in its own file.

Cons: many multiple http requests, we are are trying to get away from that! But if you don’t have a lot of SVG files, maybe this an option for you

Pros: SVG icon is only defined once, so you don’t have the problem you do with inline SVG, if you need to change it, you only need to change it in one place

  • Or should we use inline SVG tags?

Inline is basically just putting the SVG code right inline in the page, just like it sounds.

Cons: it’s inline, therefore any changes that need to be made to one tag, have to be made to the rest, AFTER you find all the tags; this is a big con, and, because of that , this solution is probably a last resort for most of the icon SVGs being used, at least in my project

Pro: easy to understand and implement, just add the tag to the page, and you’re done! Also, NO additional http calls! Probably a good solution for one off complicated images or graphics, maybe also a logo in the header (which is what I was considering this approach for)

 

And the verdict is?

 

In the end, we used an inline SVG for more semantic elements (like the logo), used an icon font for most of the rest of the icons on the site (built from the SVG that was built from the original design), and occasionally used a background SVG from the stylesheet, where we needed multi-colored icons. We are loving the device-agnostic and resolution independence of SVG and the icon font for our current responsive build, and it was well worth the trouble researching a best solution.

I will talk about using an icon font in a future post, but for now, if your browser restrictions allow it, I would definitely give SVG a try! Check out CanIUse.com, to see the browser requirements for using SVG: http://caniuse.com/#search=svg

 

Resources list:

  1. CSS SVG Image Sprites – Retina Ready, WTF?! https://coderwall.com/p/ohwa5g
  2. Icon System with SVG Sprites http://css-tricks.com/svg-sprites-use-better-icon-fonts/
  3. How to Use SVG Image Sprites http://www.sitepoint.com/use-svg-image-sprites/
  4. Why Aren’t You Using SVG?http://code.tutsplus.com/articles/why-arent-you-using-svg–net-25414
  5. Scalable Vector Graphics: an Overviewhttp://www.sitepoint.com/svg-scalable-vector-graphics-overview/
  6. Accessibility Features of SVG http://www.w3.org/TR/SVG-access/
  7. Using SVG http://css-tricks.com/using-svg/
  8. Structuring, Grouping, and Referencing in SVG – The <g>, <use>, <defs>and <symbol> Elements http://sarasoueidan.com/blog/structuring-grouping-referencing-in-svg/