SVG Rendering In Browsers

I noticed some strange inconsistencies across browsers when exporting .svg’s for a recent project. Safari renders .svg’s based on coordinates, Chrome renders vectors optically. This applies to straight objects as well as curves. For example, by default if a circle is drawn on whole pixles the shape will render with hard edges.  It’s become best practice to decrease the circles height and width from the center by a few half pixels to reduce the hard edge and make the shape look optically correct on 72dpi screens. In addition to Safari and Chrome, Adobe Illustrator CS6 has trouble displaying pixel results in .svg files as well.  The different vector renderings make it difficult to keep consistency in Ai and cross–browser.

Although .svg’s may lack visual consistency, their strengths aren’t necessarily in pixel-perfection on 72dpi screens. As the web moves further from static images to elements that animate, we should consider .svg’s for their real advantages; interactivity.

Illustrator vs. Browsers

There are some visual kinks when viewing a .svg in Ai’s ‘pixel preview’ mode. Illustrator does not render the shape true to form. But if the asset is loaded in-browser the shape renders correctly. To know how the .svg is truly looking on a 72dpi screen, you must continually save and reload the file in a browser to know what you’re actually making.

SVG Rendering In Browsers

square.svg in Illustrator on the pixel under pixel preview

The above screenshot shows a 30px by 30px square.svg file opened in Illustrator. Making a .svg in Ai and turning on pixel preview gives us this result, a square that seemingly lives on half-pixels although it’s coordinates are on the pixel grid. Notice the grey edges surrounding the 100% black field. To our eyes, this is not pixel perfect. But strangely every point is indeed on a whole pixel.

SVG Rendering In Browsers

square.svg opened in Chrome

Confirming that coordinates are the best judge on the final visual form, viewing the square.svg file in-browser reveals a pixel perfect shape.

 

Browser vs. Browser — The Circle Test

SVG Rendering In Browsers

circle.svg placed on whole coordinates in Illustrator shows half pixels

This icon was created in a 72dpi Adobe Illustrator CS6 document, making sure it was optically correct and all edges lived on whole coordinates. Saving the icon out as a .svg retains all coordinates, but strangely when viewing the file in ‘pixel preview’ the circle looks to be on half pixels (Notice the edges of the quote mark). Although the points are on whole pixels, Illustrator ‘pixel preview’ renders them as half pixels.

 

SVG Rendering In Browsers

circle.svg opened in Safari

Opening an icon.svg in Safari renders the circle true to it’s coordinates. Notice the harsh edge on the top and left of the circle. If we were to make this is Ai, we would decrease the width and height of the circle from the center to make it optically more pleasing, but Safari simply displays the circle as-is. The squares that makes the quote marks are rendered on the pixel, true to form as well.

 

SVG Rendering In Browsers

circle.svg opened in Chrome

Chrome renders the circle differently. Although the circle was created on the pixel grid, chrome will do the math for you to display it optically correct.  It takes into account that although a circle’s width and height are whole numbers, it changes the shape slightly to do the work for us; it makes the circle (more or less) more optically pleasing on it’s own. It will automatically shrink the circle from the center a few eights of a pixel to remove the harsh edges.

 

Browser vs. Browser — The Line Test

SVG Rendering In Browsers

line.svg line is drawn with a 1pt stroke

Let’s take this logic and apply it to a stroked line. As with the rectangle and circle, Illustrator renders the shape as though it is not on whole pixles, even though the shape has been drawn on whole number coordinates. The .svg is saved out with an object that retains the properties of being a line with a 1px stroke, this shape is not outlined.

 

SVG Rendering In Browsers

line.svg opened in Safari shows half pixles

Safari shades the 1px stroke slightly, so there are whole pixels that make up the arrow as well as half pixels. This may make the shape bolder, but it’s also adding more pixels than desired.

 

SVG Rendering In Browsers

line.svg opened in Chrome is pixel perfect

Chrome displays the 1px line differently. It avoids shading and makes the arrow pixel-perfect. This is how the shape was intended to look. If we were to export this as a .png, the arrow would have been created with single blocks similar to the way pixel art is created.

 

Browser vs. Browser — The Outline Test

SVG Rendering In Browsers

line.svg line is drawn with a 1pt stroke and outlined

In the third experiment we’ve not taken that 1pt line and converted it to outliners. It’s a filled, full vector shape. Note this screenshot is not in Ai’s ‘pixel preview’ mode.

 

SVG Rendering In Browsers

line.svg opened in Safari shows half pixles

Safari renders the shape the same way it has previously, some solid pixels and some half pixels.

 

SVG Rendering In Browsers

line.svg opened in Chrome shows half pixles

Chrome renders the shape the same way as Safari. This is understandable, we now have a vector shape with a fill as opposed to our previous experiment where the shape was a line with a stroke. In certain situations it may be best to leave the artwork with strokes instead of expanding and filling shapes.

 

Conclusion

It seems as though we either make shapes that Chrome will render as pixel perfect, or mathematically change the .svg file so Safari displays the asset pixel perfect. If we do cater for a certain browser that means whomever isn’t viewing the graphics in the specific environment won’t see a pixel-perfect form, and therefore we don’t have control over the way a graphic is displayed. It leads to wondering if the lack of control on .svg’s are worth using in a web where most browsers are still lower resolution when we can always have control over how .png’s look. We can Design for now and have pixel-perfect icons we’re positive will look good, or design for the future and higher resolution screens where this problem will not exist. When making elements that the browser will render we must take into account how the software will display the asset, and if it’s the best technique to display the graphic the way we’ve designed it. After all, we’ve gotten pretty good at using .png’s to make super sharp pixel’s for high and low dpi screens.

The solution could be answered depending on your end goal. What .svg’s lack in their visual control they gain in the ability to animate and react. As seen in some fantastic tutorials on codrops and the ever growing collection of great interaction design on Hoverstat.es, there are endless possibilities that allow further personality and interactivity to a graphic. As the web grows and screens become more densely packed with pixels, it seems the craft will deviate from elements being pixel-perfect to how they express the right interaction appropriate for the site and brand. In the end, it comes down to what is right for what you’re trying to communicate and technically how it will be efficiently made for the screen.

 

Here are a few other .svg resources — A List Apart and SVG Icons FTW