Tag Archives: SVG

Internet Explorer and the centered background SVG problem

We are rapidly approaching, I believe, a time when we no longer need to worry about things that don’t work in Internet Explorer.

But we’re not there yet.

I’ve started using SVG images on the web a lot, especially for logos, which I tend to put into a flexible-width container at the top left corner of pages. Which is great, except IE has this annoying habit of resizing the canvas for SVGs to fill the container they’re in. The whole logo appears on the page, and scaled properly… but it’s horizontally centered in the container, rather than flush against the left edge.

There appear to be many possible solutions, but for a solution that is 100% fluid/responsive (that is, it will scale with the container), this does the trick.

It does involve manually editing the SVG code, but it’s simple and you only need to do it once as part of the image prep process. In the <svg> tag, look for the viewbox attribute. It will most likely consist of four numbers… 0 0 followed by the width and height of the canvas. After this attribute, simply add width="x" height="y" with the same x and y values from the viewbox attribute.

It works!

Tips on saving vector images from Adobe Illustrator for SVG web use

With Internet Explorer 8 end of life coming on January 12, all kinds of new possibilities are opening up to us web developers who can finally start making use of technologies that have had wide support in modern browsers for years, but that we were reluctant to embrace because of the need for IE8-friendly workarounds.

For me, one of those things is SVG images. In recent years, especially since Responsive Web Design (and high-resolution displays) took off, I’ve been receiving web designs more and more in Illustrator format, rather than Photoshop. It’s great to get these assets as vectors that I can scale and size as I need in my build-out of high-res, responsive websites. But until now I had still been pulling vector assets over into Photoshop and producing multiple carefully-sized versions of things like logos and custom icons.

Now, however, SVG is a viable — in fact, preferable, given its flexibility and smaller file size (plus the ability to hack the XML code right in the image files themselves) — alternative to multiple PNGs of every image.

The thing is, while I have been using Photoshop extensively for over 20 years, I’ve never really gotten the hang of Illustrator. I know just enough to go into an Illustrator file, pull out the assets I need, and try not to screw anything else up in the process. That’s what this article is for.

Over the past week I have pulled a number of vector assets out of Illustrator designs as SVGs for a couple of projects, and I’m starting to get the process down. Here’s what you need to know.

The Steps

1. Select the object you want to make into an SVG. Most of the time designers will have grouped the pieces of the object together, so just a single click on the object will select it. Make careful note of the blue outlines to be sure everything you want is selected (and maybe even more importantly, that nothing else you don’t want is). You can also click and drag to select all objects within an area, or use the Layers palette to select the elements. This can be tedious, but be sure you’ve got what you need — and only what you need — highlighted. Once it’s selected, copy it to your clipboard.

2. Create a new document in Illustrator. Default settings are fine. Once the blank document appears, paste in the copied object. It should appear centered in the document. There should be a ton of space around it. That’s good. Since we’re dealing with vector art, scale is irrelevant. You just want to make sure everything fits within the boundaries of the document. (The “artboard” if you’re familiar with Illustrator speak.) Keep the object selected (blue outline). If you deselected it, just Select All.

3. Shrink the artboard to fit the object. If you don’t do this, you’ll end up with a bunch of blank space within the defined dimensions of the image and it will be impossible to work with. Good thing it’s super easy. With the entire object selected, go to Object > Artboards > Fit to Selected Art and you’ll get a perfect container.

4. IMPORTANT! If there are transparency effects within the object, you need to flatten it now. A lot of the time you can skip this step. But if you do, you may find that parts of the design are missing in the resulting SVG. I found it’s easy to forget this; I don’t find it intuitive that this would get lost in the SVG conversion. So go to Object > Flatten Transparency… Review the settings here to ensure you’re happy with them (sorry, I don’t have a lot of guidance here), and click OK Your image should not look different. If it does, undo, and repeat with different settings in the Flatten Transparency dialog.

5. Save. There’s no “Save for Web” option for SVG. Just regular ol’ “Save As”. Be sure to set the Format menu to SVG (svg). You could try compressed, but really SVGs are pretty small anyway, and I like to keep the code editable so I can tinker with it if needed. (Changing the color fill, for instance.) Once again there are a ton of settings presented in the SVG Options dialog, but I’ve found the default settings seem to work fine. (One change I have made is to set CSS Properties to Presentation Attributes but I’m not entirely sure yet what difference it makes.)

That’s it! You should now have an SVG ready for placement using an <img> tag, or as background-image in CSS. Just note that CSS treats SVG images a bit differently than regular JPEGs and PNGs, so you may need to add a few extra properties to keep the SVGs within their container elements in your page.

Bracing for the HD web

Joshua Johnson has an excellent new post over on Design Shack called Ready or Not, Here Comes HD Web Design, discussing adapting your web design techniques for the imminent HD revolution, being led by the new iPad.

I’ve been adapting my designs for the Retina Display on the iPhone 4/4S for a while now, but it’s easy enough to build a responsive web design that just shrinks down large desktop website images to half their size for display on a tiny iPhone screen. Making an essentially desktop-sized display support high-resolution graphics is a whole other story, and even though I knew (or presumed, along with the rest of the world) that a Retina iPad was coming, I think some small part of me was still in denial about what it would mean for web design.

Well, that future is here. Sure, most of the world is not browsing the web on a Retina Display iPad. But if you think the HD revolution ends there, think again. It’s just getting started. I’m about to enter the implementation phase on a handful of big web projects over the next month. Accommodating the new iPad’s display is going to be one of my top tasks.

I’ve been thinking for the past month or so that I was going to need to address this, and I’ve made the decision that, moving forward, on any site that has responsive web design as a component (which will probably be all sites I do), full-size “Retina Display” graphics are essential.

I posted a comment on Joshua Johnson’s post, where I noted that “Retina” (or, to avoid using Apple’s marketing term, “HD web”) graphics don’t really need to be 326 pixels per inch (ppi), the iPhone 4/4S’s resolution, or even 264 ppi, the new iPad’s resolution.

The standard practice with web images has always been to render them at 72 ppi, but the fact is, browsers don’t care what resolution an image is set to. A pixel is a pixel, and web images get displayed at the screen’s native resolution (unless, of course, you resize the image dynamically in the browser using HTML dimension attributes or CSS). The Retina Display approach Apple uses is to simply double the resolution (quadrupling the number of pixels). Web images by default get “pixel-doubled” in this scenario, displaying at the same relative size as they would if the iPad still had a low-res display, but appearing pixilated or blurry as a result.

You don’t need to render your images at 264 ppi for display on the new iPad. In fact, you can leave the resolution at 72 ppi, because the browser still doesn’t care. (Well, maybe it does; I haven’t actually had an opportunity to test it, but I strongly suspect the answer is no.) You just need to make the pixel dimensions of the image twice what they were before. In fact, even if you do change the resolution, you still need to double the dimensions. That’s the key.

After mulling all of this over for the past week, I’ve decided I’m going to have to get a new iPad (what a hardship, I know). I could technically do this work without it, but I think it’s important to be able to see what I’m producing, if for no other reason than to remind myself how important it is.

This is going to be an ongoing process, and because web design (or, more accurately, web design implementation — I usually work with designers who produce the initial UI in Illustrator or Photoshop) is only one part of my job, I can’t give it my undivided attention. But it’s something I am preparing now to immerse myself in as fully as possible. From now on, this is just how I do things. And with that in mind, there are some key points to consider:

1. Some images are more important to represent high-res than others. Logos, absolutely, 100%. Design elements that are on all pages (backgrounds, borders, navigation) come next. One-off photos are not as critical, but probably still are if they’re on the home page. But consider the next point as well.

2. Bandwidth is a concern. I’ve been somewhat dismissive of this up to now, as I’ve been focusing on high-res logos for the iPhone’s Retina Display — it can just take the regular web images and show them at half size to achieve high-res — but if you’re suddenly talking about downloading 4 or 5 high-res photos for a home page slideshow, it’s going to be a problem. Making users with standard resolution download unnecessarily large images is bad; making iPad users eat up their 4G data plan downloading your perfect-looking photos is bad too. Most of the attention paid to bandwidth in this discussion that I’ve seen so far has focused on the former, but both need to be addressed.

3. CSS and SVG. Joshua Johnson talks about this in his post. If we can render elements using CSS instead of images (things like curved corners, gradients, shadows, etc.), we should do that. More complex vector graphics can be displayed in SVG. All modern browsers now (finally) support SVG. Up to now it’s been a cool but essentially useless technology, due to lack of widespread support. But IE8 and earlier don’t support SVG, so if those browsers matter (and unfortunately they probably still do), you need a backup plan.

It is an exciting time to be working in web design and development. More and more, the challenges center around adapting your techniques to take advantage of cool new features and capabilities, not accommodating the limitations of crap browsers. But they’re still challenges, and we’re just beginning to discover their depth, along with their solutions.

Update: Over at Daring Fireball, John Gruber just linked to Duncan Davidson’s post detailing an issue with WebKit (the rendering engine inside Safari) automatically scaling down images above a certain size, specifically over 2 megapixels. Looks like sending huge, high-res images to the new iPad might present even more challenges than the ones I’d been considering.

I still don’t have that new iPad, so we’ll see what happens when I get it. (Tomorrow?)

Update #2 (March 25, 2012): A few more days have passed, and more has been learned on this topic. Duncan Davidson has a follow-up post that further explores the issue and a tentative path forward.

P.S. I did get that new iPad, and Duncan’s demo of an 1800-pixel JPEG on the iPad’s Retina Display is truly impressive. But what I find really interesting about it is that the 1800-pixel version of the photo looks better than the 900-pixel version even on a regular computer display… because, as I’ve observed, WebKit downscales images better than Photoshop does.