Logo Solutions

I’ve never been the best at logo design, I’ll admit to that. I applaud people who are good at it, but it’s never really been my strong suit nor my interest. And I’m okay with that.

What does interest me is taking a logo and making it look as good as possible on all screens. I’ve always been bothered, like I’m sure all designers are, by seeing logos on websites that are highly compressed JPGs. Often times they have a white background even though the site’s background is not white. The first crime is the noticeable compression1, the second is the lack of transparency.2

If you fix these two issues, you’re heading in the right direction. Most sites can at least accomplish this, however not so much when it comes to small businesses that either a) had their site created years ago and haven’t updated it or b) paid little or no money to get a site built using their host’s drag and drop website builder or maybe even a Wordpress template if they’re lucky.

The Next Step

Beyond this, the issue now is about mobile—and by extension, speed. I’ve said it before, I am obsessive about increasing site speed and getting rid of bloat3. For me, just having a logo that looks good isn’t enough. I want it to have a light footprint and look good on my crisp retina displays (Macbook and iPhone). To do this there are several approaches one can take:

  1. Create an image at twice the resolution needed and size it down in CSS, adding to the page using img. This is the easiest solution. And by easiest, I mean laziest.4
  2. Create both a double-resolution image and a regular-resolution image and use a polyfill like Picturefill or Retina.js so only the appropriate size gets downloaded by the device. This is an improvement and tends to be more useful beyond just a logo. If this were a site that served up a lot of images, I would implement something like this (and probably will soon enough). However, I currently do not use any images beyond icons and don't plan to use many in the short term.
  3. If your logo is or can be vector, use SVG (in an img element or, preferably, inline). This was the original approach I was going to take.
  4. Take your image and convert it to a base64 data URI.

Let’s explore those last two options.

Using SVG

My previous job was working in flexographic pre-press. I did preflighting, prototyping, quality control, and production work. In pre-press, image resolution and quality is everything. We were creating printing plates at insane DPIs (think in the thousands). As I was on my way out of the company, we were just getting into something called HD Flexo which would produce plates at 4000 DPI. Naturally, beyond the photographs you see on chip bags, the majority of our time was spent in Illustrator fixing or recreating art in vector format. I got really good at Illustrator and recreating poor-quality art. By the end of my tenure there any recreate5 that came in was sent to me (possibly because it was a big time suck and the more senior people had better things to do...).

What I’m getting at here is that vector is my natural state. If something can be created in vector, you can be damn sure I’m going to do it (even if it can’t, or is difficult, I’m going to at least attempt it). The file size and scalability convinced me early on on the benefits of vector. So naturally, I want to use SVGs on my sites so I can have one file (or string of markup) that looks beautiful and crisp on any screen and at any size (imagine creating one logo that can be used all over your site at any size—what a world!).

So I made my logo (using the indispensable Sketch) and exported it as an SVG. Since I was placing this in my header, I wanted it to be a link back to my homepage. I made it inline to save on the HTTP request (and also so I could style it in CSS). However, there is a Chrome bug that prevents CSS3 transitions from working on inline SVGs that are children of a elements. Since I like using transitions and all my other anchors are using transitions, it would be inconsistent to have my logo not use a hover-state transition when everything else does. The proposed solutions over at Stack Overflow were either not working or weren’t possible (can’t use PHP on a Node.js site and didn’t want to implement a server-side solution).

On top of all of this, even when I got transitions to work (using SVG in an img element), the transition from red to gray was all wonky and choppy. So SVG was out.

Data URI to the Rescue

Again, I am obsessive about reducing page load, so I have always been interested in data URIs (at least, ever since I first read about them). Since SVG wasn’t going to work and I wanted to eliminate the HTTP request, I decided to take my PNGs and convert them to data URIs. Since I was using PNGs and not SVGs, now I had to worry about separate images for retina and non-retina screens (or so I thought, more on that in a minute). So I create logo.png and logo@2x.png.

To convert them to data URIs I used the webSemantics image to data URI convertor tool. But first I used the wonderful Yahoo! Smush.it tool to (visually) losslessly compress my PNGs. Each PNG got smushed at least 50%, some upwards of 80%. When you care about page load and mobile users on spotty connections, this is quite significant—even when it’s 10KB or so!

I took my newly smushed PNGs and ran them through the webSemantics tool and used the outputted data URI and placed it in my CSS as a background image. I chose this versus inline for two reasons:

  1. Easier to manage device resolution media queries in CSS.
  2. My CSS is being cached and gzipped, significantly reducing its file size and need to be re-downloaded on future pages/visits.

So I had data URIs as background images in my CSS for both retina and non-retina versions of my logo (both normal and hover states), plus the Twitter icon in my footer, and the endmark I use. This worked great! ... but it accounted for over 50% of my CSS file size. Pre-gzipping, my CSS (minified, of course) was at 86KB. That’s pretty hefty for a simple site like this (granted I added Prism and Bigfoot and Fancybox to my site’s CSS file, but still). However, gzipped it was only 46KB—a pretty decent reduction.

The cool thing about the upcoming picture element is that the browser will only load the image that it needs, saving bandwidth (especially important on mobile). However, since my retina and non-retina images were in my single minified CSS file, both sets of data URIs were being downloaded by every user, regardless of whether it was needed or not! So I figured if the images were already in the same—and only—CSS file, why couldn’t I just use the retina version of the image and scale it down for non-retina screens? This is a variation on choice #1 above, which I poo-pooed. Having one image that is scaled down for non-retina screens isn’t too bad though when it’s placed in a minified and gzipped CSS file.

By eliminating the non-retina versions of my logos and icons, I reduced my pre-gzipped CSS from 86KB to 57KB. After gzipping, my minified CSS comes in at only 26.7KB!

Seeing as just a single state of my pre-smushed retina logo was 26KB, this is pretty amazing!

Concerning Accessibility

Learning to make sites more accessible is on my learning list. I was listening to episode 64 of The Web Ahead earlier today. It featured Dale Cruse and a talk about accessibility on the web (Dale prefers to call it accommodation). He made a compelling argument why we should care about accessibility—it affects more people than we think and in different ways than we typically think. The question I’ve come across when dealing with clients or colleagues is “why?” It seems to me the more appropriate question is “why not?” It’s not difficult to make sites accessible and if we as web designers and developers are doing our jobs correctly and implementing web standards from the start, we’re more than halfway there. This is becoming a long digression to basically say I wanted to make sure my logo wasn’t just a mysterious h1 in my header.

If I were placing my logo using img, I could very easily add a descriptive alt attribute. Not the case with CSS background images. Typically it is recommended to only use CSS background images when they are non-essential to the page. You really can’t get more essential than the site logo in the site header. To combat this disadvantage of CSS background images, I used an admittedly hacky solution: text within the h1 and using the following CSS:

h1 a {  
  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;

I found this technique over at Zeldman.com by way of Sitepoint.

I know this is not the preferred solution. Unfortunately, alt text is not an option. At least it is better than the text-indent: -9999px technique that I was originally using.6

And Finally

Knowing what I know now, I’m not sure I would still go with SVG if the Chrome CSS3 transitions bug didn’t exist and the red-to-gray transition wasn’t janky. I would have to re-evaluate the pros and cons when the time comes as to the best way to handle this. At the moment, with only five (including hover states) icons as data URIs in my CSS, it’s not a big concern about adding to the size of my CSS file. In the future, if I start to add a lot of icons to the site, I’ll have to investigate other ways of implementing these icons.

  1. Nothing wrong with compression, as long as it doesn’t degrade the image’s quality return to article

  2. If the logo requires transparency, that is. return to article

  3. I’ve been chipping away at my to-do list, but more on that later. return to article

  4. I suppose the laziest solution would be not even creating a 2x resolution image. return to article

  5. Typically, we were either sent a section of packaging from a printing press or given a printout of a package and told to remake it in Illustrator because the original art files were either lost or unavailable for contractual reasons. return to article

  6. A major downside of this technique being that the browser actually draws a 9999px box offscreen, wasting resources. return to article