The Curious Case Of The Safari SVG Scrollbars

One of the main considerations when developing the new Freakyleaf website was how to future-proof the site’s graphical elements. For the vast majority of sprites and graphics, it was a real no-brainer to choose SGV (Scalable Vector Graphics) over traditional file formats (such as JPG, GIF and PNG), to deliver resolution-independent visuals (with a suitable fall-back in place for those not-so-well-endowed web browsers, of course).

So with this mind set I went about creating the various graphics for my website, including the main logo (the one top left of this very page). This was created in Adobe Illustrator and saved out as an SVGZ (Compressed SVG File), to reduce overall file size. I made sure that there was no wasted space around the logo by selecting “Object -> Artboards -> Fit to Artwork Bounds” whilst working on the file in Illustrator.

So far so good.

As any respectable web developer, I regularly check my designs in as many web browsers as I possibly can, to ensure that each one renders the site’s elements correctly. Having checked in all the usual candidates (Chrome, Firefox, Internet Explorer), I decided to check my efforts in Safari (version 5.1.7 – what appears to be the last ever Windows version as of December 2012). Not so good.

Okay, so the scrollbars are weird enough, but what struck me was that a) they were really small and b) they weren’t scrollable (i.e. they were part of the image itself. By using Chrome’s ‘Page Zoom’ I was able to get a little more detail:

So with the scrollbars being rendered as part of the image, it was either something to do with Safari’s rendering, or the file itself; turned out it was a bit of both.

As SVG doesn’t give an exact location for each pixel (such as with JPG, GIF and PNG files), it’s down to the browser to interpret how to render the image. A parallel can be drawn to font rendering, which can look remarkably different from browser to browser. The fact that I’d clipped the file in Adobe Illustrator so tight left no ‘wiggle room’ for browsers’ renderers, and it just so happened that Safari needed that little bit of ‘wiggle room’.

Above is a screenshot taken from Adobe Illustrator, where it appears that the bottom half of the logo symbol neatly fits within the bounds of the artboard. All very well, but what we’re viewing is Illustrator’s interpretation of how the image appears, based on the program’s rendering engine. Whilst fairly accurate, it doesn’t factor in how other programs may render the same file. It just so happened that Safari renders the same file an extra half a pixel wider and taller, necessitating in the ‘need’ for scrollbars to be drawn onto the image by Safari (I’m sure there’s someone at Apple HQ who knows the reason why).

So, how I did I resolve the Curious Case of the Safari SVG Scrollbars? I simply enlarged the artboard size of the Illustrator file by 1 pixel both horizontally and vertically and resaved the SVGZ file, allowing any SVG rendering engine that likes to render SVG files just a little bit differently to the norm (Safari) the wiggle room it so needs. Problem solved!