Vector graphics are slowly supplementing bitmap images and have become a cornerstone in modern web design for an amazingly simple reason: because they are composed of mathematically defined coordinated rather that a fixed number of pixels, they scale up and down with no loss in quality. This fact makes them great for responsive web design (a single site whose layout scales and reflows according to screen size, mostly removing the need for a separate site for mobile devices). Slowly but surely, vector graphics are being used in place of bitmapped buttons, small simple images, and layout elements (such as a navigation bar) in websites. Already it makes more sense in the corporate world to design a logo in vector instead of bitmap so as to scale it for any advertisement size and layout, the same with many mobile applications too, so website designers are now adopting this trend fueled by the explosion of smart phones, touchscreens, and tablets of varying sizes.
Thankfully, web browsers and website frameworks have noticed this trend and have done their best to support vector graphics, mainly in the form of SVG files, which are either saved as an external file and loading using an
<img> tag or through inlining the file (much like using a Base64 encoded bitmap image) using the
<svg> tag. Today, any web designer can create a SVG vector image using any vector graphic creator, such as Adobe Illustrator or Inkscape, add it to a website, and have it rendered and ready for scaling in every modern web browser.
That is, except for Internet Explorer.
For as long as website design has been seriously considered, Internet Explorer has been a major force to be reckoned with, either for good or bad. As the browser with the most market share, developers are often placed in an all-or-nothing support situation, with some degree of support being performed most of the time. Further complicating the matter is the various versions of IE in use, mainly ranging from IE 8 to the newest IE 11. While IE 10 and 11 are drastically improved compared to the last few versions, there are still plenty of standards compliance issues designers and developers alike must workaround without crippling more compliant browsers. One such IE issue that must be dealt with even in the newest version is (surprise!) SVG support. However, the issue is not as simple as it sounds. Although Internet Explorer supports SVG graphics, it has a beef with SVGs exported from Inkscape (but not from other Vector graphic editors), even when using the “Plain SVG” Save As option.
In this post, we are going to be exploring this strange scenario, why it happens, and how we can avoid having Internet Explorer choke on our beloved vector graphics. A live demo of the issue at hand is available at http://le717.github.io/demo/ie-inkscape.html. You will need to use Internet Explorer to view this. However, I have provided screenshots of the issue, though, as it makes everything much easier to comprehend when you can see what is happening (and making up for the Impossible, unless you know how cross-browser support). ;).
Consider the following image:
Obviously, it is a 500×500 grid with specific coordinates marked. If we were to use this SVG image, which we created in Inkscape and saved using either the “Inkscape SVG” or “Plain SVG” Save As option on our website, but needed to size it down to, say, 250×250 (which is oh so conveniently marked on the image), we would expect to see the following result, namely, the graphic resized to 250×250 and still showing the entire graphic.
Indeed, this is how it looks in all browsers except in Internet Explorer (but you already got that much). Instead, the exact same graphic looks like the following (Exhibit A in the live demo):
(*sigh* Again with the
1px white edge…)
As can be seen in the image, Internet Explorer clips half the image on both the X-axis and Y-axis. If we were to open the F12 developer tools and check the computed width and height on the image, we would find they both equal
250px. This means IE halved our image in multiple ways: canvas and viewport size! Clearly, we only want it to change the canvas size. If you are like me, you might think the answer would be to simply double the image’s (not the container size) width and height (so 1000×1000) on just IE. Well, that doesn’t work…
While our grid image is now fully displayed, the image container size is now twice as large as the image! Sometimes, this change doubles the image size to fill the entire container, making the image 1000×1000! This would be a massive pain to work around in your site design, not to mention an undesirable and unpredictable implementation.
Phew! Now that we know in detail all about the issue Internet Explorer has SVGs from Inkscape, what can we do to avoid this catastrophe? We could always complain to Microsoft and hope they fix this in IE 12, but we would still have to work around IE 11 and lower. But as you already knew, I have a (more) practical answer. 😛
Get Adobe Illustrator.
No, wait, come back! Don’t leave me now! D: I hate those types of answers just as much as the next guy. Just because it the industry standard and works correctly does not warrant the reason or lazy excuse to purchase a $600, 1-year subscription to Adobe Creative Cloud (or buy a legal copy of CS6 for the same amount). Not everybody has the money for such an expensive (yet powerful) software suite. I am still not totally happy with my forced purchase (*long story here*) of an Adobe CC subscription. I will say that if you do have or can gain access to Adobe Illustrator, you should use it. I have been slowly playing around in it, and it gets the job done. That being said, is there a fix for those who cannot afford this software (including myself)?
Upon closely inspecting an SVG export from both Illustrator and Inkscape, I discovered the inclusion of a single line, an attribute, in the
<svg> tag at the top of the file in the former’s export that was not present in the latter’s. Adding this attribute to the Inkscape export happily fixed Internet Explorer’s resizing issue. The attribute is as follows:
viewBox="0 0 500 500"
MDN’s documentation for this attribute explains the very direct name.
viewBoxattribute allows to specify that a given set of graphics stretch to fit a particular container element.
The value of the
viewBoxattribute is a list of four numbers
height, separated by whitespace and/or a comma, which specify a rectangle in user space which should be mapped to the bounds of the viewport established by the given element, taking into account attribute
In simple terms, this attribute controls how the image is displayed at various container sizes. If you look at Exhibit B, which has that attribute, you can see it is now displayed properly.
There are two ways you can duplicate this yourself.
- When exporting from Inkscape, use the “Optimized SVG” option in the Save As command and check the Enable viewboxing option.
I personally check a few more in order to strip out unused code (resulting in somewhat smaller files), and the Style to XML box is unused (but recommended practice from me), but enabling that option will add the
viewportattribute and fix the issue once and for all. The attribute really should be present when saving normally, but clearly it is not. It appears the other major browser’s SVG parser automatically scales the image to the container if the attribute is missing, where as Internet Explorer reads it straight without compensating for the missing part.
- Add it to the file yourself. You should only do this if you are comfortable with editing XML files properly and know how to not completely break them/fix them if they do break. 😛 Look for the opening
<svg>tag, then, consulting the required attribute format, type the line and save the file. The
heightvalue should be the native SVG size. In my case, it was 500×500.
Thine days of Inkscape SVG and Internet Explorer compatibility issues are henceforth over! 😀