Today we are performing SVG tests on the various major browsers to see why typical images don’t always get transformed or rendered properly.
SVG, or Scalable Vector Graphics, have been around since 1999, but are only recently becoming more widely supported in web browsers. Part of this is because of the anticipation for the HTML5 standard which allows for things like the <canvas> element, finally enabling website developers to draw using vector graphics directly on their web pages.
However, due to the number of variables that can alter the way an SVG file can be displayed, it’s no surprise that there can be inconsistencies between the way different browsers handle the images. Specifically in this post, I’m going to discuss SVG sizing on a page using HTML and how to fix a couple of common scaling problems between several popular browsers.
I’m basically writing this because I’m rather new to using SVG myself and made the decision to use SVG images for SEO Warp to maintain the quality of scaled images. I also wanted to practice using Inkscape, which is a fantastic tool, but at the time of this writing, many of the SVG files generated by it can lack certain parameters that browsers require in order to display images properly. So if you’ve been using Inkscape and are having problems with different browsers rendering your images correctly, this post can probably help you to solve your issues.
Before I begin, I’d just like to point out that on my test page, Internet Explorer 9 refused to display any of my SVG images on a basic HTML page until I declared the HTML4 strict or HTML5 doctypes. If you’re seeing the broken image icon in place of your images in Internet Explorer, consider adding the following to the top of your HTML document before the rest of your code:
I’m not sure why it’s necessary to do that in IE, but it’s not like declaring a doctype is a bad practice anyways.
The most common problems that I’ve seen with using SVG so far are that Internet Explorer tends to clip resized images rather than actually resizing them and that Webkit-based browsers such as Google Chrome and Safari will resize and stretch images in strange ways. Let’s take a look at both of these issues because they have similar underlying causes.
SVG Clipping Issue in Internet Explorer 9
For this test, I edited the icon for my HTTP Viewer, making it four times as large as normal and adding a little green star to its top left corner.
This larger version of the icon is 256×256 pixels, but we’re going to use our HTML img tag to resize it to 64×64. Any standard browser can resize an image with the height and width attributes allowed in this tag, and since we’re dealing with SVG, this should be even less of an issue; SVG is meant to be scaled without having to lose any quality of the image.
Here’s what the SVG looks like scaled down to 64×64 in several different browsers:
It’s pretty obvious that one of these things is not like the other. So why did Internet Explorer 9 clip our image to 64×64 rather than just resize it? Let’s check out the SVG code using a text editor (my favorite by far is Notepad++):
What we can tell from this SVG header is that the image is clearly 256×256 pixels, as defined by the width and height attributes. But as it turns out, there’s another parameter that we’re missing that IE9 is looking for: viewBox.
While the width and height parameters set the size of the image, it is the viewBox that determines the viewport of the image, or what section of the image should be seen by the user at a given time. When this isn’t present for Internet Explorer 9, instead of resizing the image with the <img> tag, it will actually use the width and height to instead define the viewBox, thus clipping our image.
So let’s edit the code a little and include our viewBox:
Here, you can see viewBox added. The parameters should be obvious to anyone familiar with plotting points on a graph:
viewBox="[Starting X Coordinate] [Starting Y Coordinate] [Ending X Coordinate] [Ending Y Coordinate]"
And in this case, it’s simply saying that the viewBox is the exact same size as the image. Now that we’ve added it, let’s take a look at how it renders in our browsers one more time:
Now that we have our Internet Explorer resizing issue out of the way, let’s see what can happen if we try rendering and resizing images with different SVG size parameters.
Common SVG Resizing Problems
In this next test, we’re going to use modified versions of the robot icon that I created for in SEO Warp’s web crawler.
Here, we are going to take this image and plug in different values for our width, height, and viewBox parameters and see how the various browsers handle them.
The following two images have these different versions displayed at 64×64 pixels and 32×32 pixels with the HTML <img> tag’s height and width attributes respectively:
The SVG header parameters for these images are:
- height=”100%” width=”100%” … viewBox=”0 0 64 64″
- height=”100%” width=”100%”
- height=”64″ width=”64″ … viewBox=”0 0 64 64″
- height=”32″ width=”32″ … viewBox=”0 0 64 64″
- viewBox=”0 0 64 64″
- height=”64″ width=”64″
- height=”32″ width=”32″
It’s no surprise that Chrome and Safari display the images so similarly since they both use the Webkit rendering engine to draw their pages.
Here are a few things that we can tell from these tests:
The Webkit-based browsers Chrome and Safari require height, width, and the viewBox to display properly. If the width and height are either defined as something as useless as 100% or if they aren’t defined at all, these browsers will make a guess as to what the dimensions ought to be based on the points and shapes defined in the body of the SVG file. Because of this, images will tend to get squished as shown in tests #1 and #5 where the viewBox is defined, but the height and width are either useless or undefined.
Also in these Webkit browsers, if the width and height are set but the viewBox is not, the viewBox will be set to the width and height. This is why in test #2 the images are crammed into the upper left-hand corner: 100% gets converted to an actual number when the image is being rendered; we could have just told the rendering engine that the image is 4098×4098 pixels or something equally outrageous. In the SVG file, the plotted points are really small in comparison: the points for the corners that are drawing the robot’s head are defined somewhere around (16,55) (48,33). In this massive field that we’ve defined for our viewport, it’s no surprise that the image gets crammed into the upper left-hand corner.
Internet Explorer 9 seems to ignore the width and height in the SVG for the most part. It will start drawing out the image based on the plots of the shapes in the SVG’s body. The viewBox is used to define the boundaries of the image. Once IE has those, it will cut out the representation of the SVG and use that render for any HTML transformations.
The safest way to implement a basic SVG image is to set the height, width, and viewports explicitly and give them relevant dimensions, like in examples #3 and #4.
I hope this post has been helpful.