Baggage Claim

Hello, I’m Oliver (aka SuitCase.) Visit the comic I help make, dig around my old website, tweet at me, ask me stuff on the BCB blog or email me.

Retina-Ready Webcomics

An example of a non-retina webcomic site

Remember the Retina display?

Apple, 2010:

The Retina display on iPhone 4 is the sharpest, most vibrant, highest-resolution phone screen ever, with four times the pixel count of previous iPhone models. In fact, the pixel density is so high that the human eye is unable to distinguish individual pixels. Which makes text amazingly crisp and images stunningly sharp.

It’s the new normal for smartphones and tablets. “Only iPhone has the Retina display”, Apple boast, but these days we must assume they are leaning on their strengths in colour accuracy, surface lamination techniques and wide viewing angles. The truth is, everyone makes Retina displays now, from Amazon to Samsung to BlackBerry. If you own a smartphone or tablet, chances are its display has a pixel density “so high that the human eye is unable to distinguish individual pixels”. Retina.

But there’s one exception. You’re probably looking at it right now. Even in 2013, your computer is almost certainly stuck in blocky non-Retina land. Apple wouldn’t gush about it. Even your cheap friend’s $179 Kindle Fire makes it look prehistoric.

But that’s all changing. Apple is making Retina personal computing happen while Google slavishly copy. (Just kidding, tacky Android friends.) Microsoft is kinda holding up the Retina train and won’t be ready until the next Windows, but we can be nearly certain that within a few years at least Macintosh users are going to be living in a fully Retina world.

No place to hide

The 90-130ppi desktop computing “standard” has been an invisible blessing for web designers since the web began. Make a graphic, 800px wide, good enough, pick the right compression, up it goes, done. People with ancient monitors see it big and scroll more, supernerds with 1080p ThinkPads push up their glasses and enjoy the extra space on their squinty spacious desktops. And all the people viewing on their Retina phones and tablets don’t care because everything on the web gets scaled down to fit on the small screens anyway. Sharp graphics for everyone.

But the party’s over. Just go to an Apple Store and look at their Retina MacBooks. (Or drag the loupe around on their website.) Look closely at those websites. All of a sudden we are facing a generation of computers that show all of the internet at a 200% zoom level just to fill those extra pixels, and our once-sharp photos, logos and graphic elements have turned into a terrible smudgy mess.

Yeah, and…?

It’s a new problem for everyone who publishes images online, and one that hits webcomics hard. We work in a visual medium consumed largely by technologically-savvy young people with great eyesight, and sooner or not they’re going to notice that your content looks distinctly old-fashioned compared to their 1080p YouTube videos, crisply-typeset weblogs and, well, their pixel-perfect back button.

You can ignore it. I suspect that the web will be uncomfortably smudgy and inconsistent for another decade. Expectations will remain low… for a little while. But if you’re the type to sweat the details, it’s not impossible to upgrade even the sprawling archive of a 7-year-old webcomic into something that looks great on these new ultra-sharp displays.

Because I did it! And I can show you how.

(If you have a lot of time. And care a lot about retina screens. OK, FORGET IT.)

Part One: Favicons

Let’s start with the easy stuff. We all use favicons, right?

An IE7 screenshot

I won’t walk you through all of that. I will mention that you SHOULD be using the true .ico format and not just lazily renaming a .png file to .ico. Many people do this, and it’s bad bad bad! Why? Well, despite being an anachronistic dinosaur, .ico allows you to make this:

Multiple favicon sizes

Yes! That’s right. You can serve your NeXT, System 7 and Windows 3.1 customers with custom-tweaked low colour icons! And, um. Retina too. That’s the first one in the list. See how it’s double-sized?

This is possible in one file because .ico is a container of graphics, not a graphic itself. It can fit many different sizes and shapes of icon in its confines.

So while you could disregard what I’m saying and “go retina” by updating your “favicon.ico” PNG file to a 32 by 32 pixel size, the real way to get reinta-ready is to create a real .ico file with two sizes inside it. That way, retina browsers know to pick out the larger one, while non-retina browsers just take the same old 16 pixel one as always. Preferably, you’ll use the opportunity to pixel-fit your icon to each size.

There are various online services that can make .ico files for you. There’s a cheap Mac app called Icon Slate that does it too (as recommended by John Gruber, who has also explained how to use it for this exact purpose.) But my preference is Microangelo, a cheesy Windows app that lets you dig in and implement every different size of .ico.

Microangelo screenshot

It’s mostly self-explanatory. I recommend using the above size and colour combinations, just to be thorough. You might think it absurd to work on a 16-colour version of your icon to suit the zero people in the world browsing on a 16-colour display, but you’d be surprised when this stuff becomes relevant! Did you know some Android browsers use the black and white favicon? In 2013!

OK, done? Save and upload the .ico.

Not Enough Rings browser chrome

Tada! You are now making a great impression in the chrome of a retina browser. You’re already doing better than most of the websites on the internet, and all it took was one little file!

But there’s also the small matter of…

Your website

OK, OK. This part is a little more important than the favicon. But it’s also a completely different process.

There are two sets of graphics to update. The first set is the most fun to do. The second is a little painful, but I’ve figured out most of the hard technical stuff already, and I’ll tell you of the best methods I know.

Part Two: CSS

Hopefully we all know what CSS is about by now, and the general idea behind the separation of presentation from content. In a perfect world, your HTML is pure pure content and CSS is the interchangeable theme you apply to that content. Here.

Diagram of the Not Enough Rings page

Our first job is to “retinaise” these green bits. They’re the presentation, the design elements, all centrally located in the CSS. So it’s relatively easy to do this. We’ll leave the <img> (marked in orange) for later.

First of all, locate your CSS file (or files). Because I code my own sites from scratch, I know that everything is found in a single “global.css” file. Other people might have Wordpress or ComicCMS themes layered with a few different .css files for plugins and stuff. I dunno. Just find them.

Then search the .css file(s) for any line which includes this:

background-image: url(/directory/image.png);

or

background: […] url(/directory/image.png);

Those url() bits are image references. Icky icky old-fashioned non-retina-image references.

It’s those we’re gonna be changing.

OK. Got your CSS files ready? Know where all the background images lurk? Let’s begin!

The process

Open an empty text editor window. Now, read through your entire CSS file(s) and copy out EVERY DECLARATION BLOCK that includes a “background-image” or “background”. Paste them one by one into the text editor. Then, once you have your little “mess of declaration blocks with background image references in them”, strip them down to look like this:

Stripped CSS

See what I did there?

I chopped out everything unrelated to the line with the url() bit in it. Fonts, margins, whatever, I killed them all.

Then I changed anything that said “background:” to “background-image:”, and I made sure that anything about solid colours or repeating backgrounds or alignment or whatever was all stripped out, so all I was left with was the neat little “url(“image.png”)”. It’ll take a lot of text editing to compile this little chunk of CSS, but eventually you’ll get there.

And now we have a nice little list of the background-images your elements use. This is going to form the basis of an elegant little block of styles that you put at the end of your CSS to override the low-res versions for retina people.

But before we put it into the CSS and save it, we have a bit of work to do to this chunk of code. Let’s get to it:

  1. Add a background-size value to each definition, and specify the width and height of your original, non-retina image size in pixels. (Yes, this means you have to check each and every goddamn image. It’s necessary so that retina browsers know the size of the original, non-retina image and can scale it accordingly.

    EXAMPLE: For h1, which has a background-image that is 630px wide and 278px high, it looks like this:Background-size added
  2. Put “@2x” in front of your images’ file extensions. So, navbar.png becomes navbar@2x.png, funnygraphic.jpg becomes funnygraphic@2x.jpg. These are references to the retina graphics you’re gonna make in a moment!

  3. Wrap the whole set of declaration blocks in a big media query block. Media queries are a little hard to explain concisely, but you can simply think of this as the line that says “If you’re a retina browser, apply everything inside this block. If not, ignore me, move along.”
    CSS with media query block

The media query line you see is this:

@media only screen and (min-device-width : 720px) and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-width : 720px) and (-o-min-device-pixel-ratio: 2/1), only screen and (min-device-width : 720px) and (min-resolution: 192dpi) {

Just remember to indent the enclosed styles (for readability!) and wrap your chunk ‘o styles at the end with a simple “}”.

For those who are wondering, this is a media query I tweaked myself after a bunch of testing. It captures every retina-capable browser, is future-proofed and won’t serve giant retina images to the mobile phones and tablets which don’t need them.

And with that.. we’re done writing CSS! You can jam your lovely new retina override code into the bottom of your CSS file. Or somewhere else. Just make sure that this section comes after you’ve already mentioned the existing images, because remember, we need them to come in and override the earlier definitions and never be overridden themselves.

Remember, if your site uses multiple CSS files that contain image references, you will have to redo this for every CSS file you have. Or you could do the right thing and consolidate them. Same goes for inline CSS if you’re unfortunate to have it. Fixing these issues is gonna be up to you and your level of expertise!

HOWEVER: when you’re done with your CSS hacking, don’t save the newly retina-ready CSS to the server just yet! The coding part is over, but all those references to files like “header@2x.png” are going to result in “File Not Found” errors because the images don’t exist yet.

It’s time for you to make the graphics!

Making retina graphics

The best way to start on this is to gather every file the CSS refers to, put them all in a little folder on your desktop, and set up a batch process in a program like Fireworks or Photoshop that simply:

  1. Scales the image to 200% of its original size
  2. Compresses the file to the same format it was in (PNG, JPG, whatever)
  3. Adds a “@2x” suffix to the filename
  4. Puts it inside the directory on your desktop, alongside the original size.

I use Fireworks, myself. But nobody uses Fireworks. You should be able to figure this one out yourself, though. What you want is this:

A list of images

At this point, you technically have retina-sized images that are ready to upload, but they’ve just been lazily upscaled. Despite how dumb this seems, it’s very useful to make your “dummy” image files before anything else because they can act as handy templates for you to reconstruct everything.

Of course, this is where you have to spend a whole heap of time working on your graphics again. There are no shortcuts here. It will help you a lot if the graphics on your site are easily reproduced or (even better) come from giant source images you drew ages ago and kept because you’re smart

Just open each image in your editor and replace their contents with higher-res versions, one by one.

I have a few notes on this process:

  • The “@2x” suffix is just Apple’s convention for double-size image filenames originally defined in iOS, and a lot of web developers use it too. If you dislike Apple enough to pick your own, go ahead, forge your own path — just remember that you need to change the “@2x”s in the CSS code too.
  • Don’t be afraid to compress your images a little harder than usual. Retina graphics bulk up your site a lot, but retina screens can mask image compression to compensate. Strike your own balance.
  • Sometimes you’ll remake images even better than the original. Don’t be afraid to scale your retina graphics down to 50% and save over the non-2x version so they match up! Just keep them sharp and good-looking. They may not be as cool as the retina ones, but for many more years they will be the only graphics seen by the majority of your audience.

Once you’re all done, upload your @2x files to sit alongside the old ones. Save your CSS to the server, and tada! Every CSS-styled part of your site will look super-sharp on retina screens.

This leaves only…

Part Three: Your <img> elements.

Not images, <img>s. Good old Web 1.0 image elements! If you’ve been a good little HTML author, you’ve ensured that all your <img> elements are CONTENT and never PRESENTATION. You’ve probably messed up a little, to be honest, but that’s OK.

This is gonna be more complex than the CSS part, and it’s harder to track down everything you need. You’ll need to do a survey of your site to figure out where <img> elements are used. Presumably, your comic pages are served as <img>s, but maybe you have emoticons in an image section, a header graphic..

A good way to test what’s what is to use special web developer extensions to temporarily disable your CSS. Or if you’re brave, blank your live CSS file for a moment, open up all the pages on your site and put the CSS back before anyone notices!! If you do this, you’ll quickly see your site “naked”, with all the <img>s revealed.

OK, so you’ve figured out what you need to change? A few scant header pics and oh ummm YOUR ENTIRE COMIC ARCHIVE? Well.

And now the real work begins

You should do the same thing you did when doubling your CSS images. Use automated tools to duplicate them, make them 200% size, add the @2x suffix. But unless your comic archive is extremely uniform (e.g. you simply take 600dpi print-quality PSDs which you resize for the web and that’s it) you will probably have to do a lot of specific work.

For me, Not Enough Rings was easy (it was a simple set of consistently-rendered scans that I just resize down for the web) but Bittersweet Candy Bowl was NUTS. In the Volume One chapters there were all sorts of fuzzy effects that masked the pencil shading and made it look nicer, which I elected not to include in the print version because I couldn’t figure out how to recreate them.

A comparison of image filters

But GUESS WHAT? When you have to take those 600dpi edited scans and export 550 pages at twice the regular “web” size, you have to figure out all those effects again! And for Volume One I basically just gave up, because no matter what I did I couldn’t figure out how to fuzz up the pencil shading at the doubled resolution.

Not only that, I did all these tinting and halftone effects in Volume Two that I only rendered into web-resolution images back in the day. So I held back on attempting this retina upgrade until the publication of Volume 2 forced me to recreate those tints and halftone effects at a higher resolution.

Some volume 2 visual effects

Once I had the 600dpi images in hand, making retina-quality images was a cinch. But man, so much work went into getting those 600dpi images done! You can read Volume Two to see the amount of flourishes that had to be painstakingly imitated at a much higher resolution.

If you haven’t been disciplined enough to always work in high resolution, you will have to think about your comic archive very seriously. Some of you might not even have print-resolution scans of their older stuff!

For this article I will have to assume that you were forward-thinking enough to work at print resolutions, but if you were not: you will face the terrible choice of redrawing\reinking or recolouring your work. But this is the same choice you’ll consider when you go to print. Maybe it’s time to bite the bullet?

Putting your hard work to good use

So eventually you’ll end up with @2x versions of all your <img>-element images sitting alongside the old versions, dutifully waiting to be called upon. Site graphics (content I hope!) as well as your archive.

You can be missing a few, but hopefully you got most of them. With Not Enough Rings I got all of them. 8-)

Now, in an ideal world this would be the end of the article. But no, retina web browsers aren’t going to check if a @2x file exists if you don’t tell it where to find one.

Kinda dumb, right? But we work with what we have. We have to help the browser find the retina images.

Now, the problem. There’s just NO GOOD WAY TO DO THIS. There are many bad ways, and there are two slightly-icky ways (that I personally recommend.)

Let me walk through two terrible ways to do it, first.

Don’t do this!!

1. Forget the small images and just point everyone to the double-res stuff.

This… works. If all you did to create your non-@2x images was resize them down from @2x it might even feel logical! But, uh:

  • Sending oversized images to non-retina users is disrespectful of their time and resources
  • Your bandwidth use will immediately balloon, and your server will be working harder and longer for no good reason
  • Your images will look ugly on non-retina! (Browsers do smooth resizing of images these days, but a speed-optimised browser will never beat the quality-first algorithms that work inside an image editor.)

It’s just.. ugh. Do this if you care more about saving your time than doing anything correctly.

Although… if you’re not working to make the most beautiful and correct thing possible, why are you even bothering with this retina endeavour? Come on.

2. Serve the non-retina versions and include some javascript thing that tells retina browsers “Wait up! Replace them with the @2x ones!!”

This is what Apple does on their site, and fuck them! It’s kind of like doing the method above, but the other way around: it is a waste of time and resources for users with retina browsers. All of a sudden instead of a 200kb low-res image, I have to download a 200kb low-res image and THEN a 350kb hi-res image?

I guess it works. But gosh, it’s an ugly solution. (You get this weird “flash of non-retina image” effect while the page loads, too.)

The right way(s)

The right way to do it has “serve the right images to the right browser” as the core goal. That way nobody wastes any time or resources, everybody gets an image tailored to their screen and there’s no weirdness.

As far as I can tell, there are two things you can do. Both are a little ugly on the server side, but result in happy users.

Shaun Inman’s Automatic Conditional Retina Images

He wrote it up pretty well for a technical audience, so I won’t bother restating the details. But for the laypeople, let me break this method down:

First, you put a little snippet of Javascript code on every HTML page on your site. It’s short and sweet — all it does is set a cookie that says “I am a retina browser!” if it is run by a retina browser.

Then, to complete the process, you put a .htaccess file in the directory where your <img> element images live (or multiple directories.. e.g. /comics/, /theme/, whatever) that tells your web server to check for the “I am a retina browser!” cookie, and if it exists, serve the @2x version to the user.

And then you’re done. Non-retina browsers never get the cookie so they are sent the non-@2x file. And it will supply the non-retina graphics to retina browsers if it can’t see an @2x file uploaded beside it.

This is what I would like web browsers and servers to figure out on their own, really.

Some issues here

Inman notes that there are some situations where the browsers load images before the cookie is set, which really does happen a lot — the first page loaded by your retina user is often in low-res because the cookies weren’t set in time for the web server to see them.

I also noticed a few other things that felt yucky to me:

  • Using an nginx proxy to serve your static content? Guess what, this is Apache only! Time to make some exception rules…
  • CDNs won’t be able to run the .htaccess that checks on the cookie before serving files, so you gotta host your images locally again
  • Inman’s cookie doesn’t have a long expiry date attached, so that “first page load” experience happens more often than you’d expect.

I solved all of these problems, but it wasn’t pretty.

(Well, except for the cookie thing. Use this line instead of Inman’s. It sets the cookie for a longer time.)

<script type=”text/javascript”>if((window.devicePixelRatio===undefined?1:window.devicePixelRatio)>1)document.cookie=’HTTP_IS_RETINA=1;expires=Wed, 1 Jan 2020 12:00:00 UTC;path=/’;>/script>

An ugly improvement

I think you should write PHP that checks for the cookie and puts a @2x in the URL of every <img> on your page if the cookie is present.

Yep. PHP. Start your page with this:

And every single goddamn time you use an <img>, do this:

<img src=”/img/introsamples/intro_sample1<?php print($retsuffix); ?>.png” width=”950” height=”696” alt=”Augustus and Lucy chat about Daisy”>

(I use PHP, but if you live in a nicer world than I then you can probably translate this code to your favoured language pretty easily.)

These PHP snippets are intended to do the front line work of sending those users who got the retina cookie (from Shaun Inman’s method) leaving the .htaccess as a weird little fallback for when you forget.

This is mainly useful for the purposes of ngnix proxies, CDNs and other “dumb” web servers that aren’t going to be able to do the .htaccess stuff for you. It also minimises behind-the-scenes Apache redirects which I find philosophically icky.

The worst form of retina <img> support, except for all the others.

Let’s not pretend this is a neat and tidy way to do things. The CSS and favicons were easy enough, but the state of the web right now is that serving <img>s in retina resolution is a difficult problem to crack.

Even with my multilayered solution, you are still going to have to deal with non-Javascript users never receiving your retina cookies and missing your retina images. You can’t fix the problem where the cookie gets set after the images start loading. And, worst of all, you’ll need to get PHP (or similar scripted languages) running on static pages where you might not want such stuff.

BUT! It works, well enough. Go look at the two sites I’ve been using as examples: Bittersweet Candy Bowl and Not Enough Rings. I think they work pretty well!

And look. If you’ve been good, you’ll find most of your pages only have one or two <img>s anyway. It’s not great, but it’s.. tolerable. (Tell me if you can figure out something better.)

So.

Favicons, CSS, <img>s. Are we done? Well, let’s not forget

External content

Horrible mixture of sharing icons.

And this is where you give up.

Your users are going to upload non-retina images. Your social networks might provide you non-retina buttons. Your ad providers are going to serve non-retina ads. (Though, in a strange twist of fate, the Flash ads are going to have nicely upscaled text and vectors!)

And you have to live with it. You can’t control them. It’s a sad little thing to mar your beautiful webpage but I think in most cases it’s not gonna bother you too much. You can see above that a few of these external services are already on the retina train… it’ll just take time for everybody to catch up.

A few things I missed

There are certain issues I haven’t touched on here. Some have argued that it is effective to produce big but overcompressed images, others talk about SVG and web fonts. You can even just resort to CSS trickery and avoid image formats entirely.

But that’s not what I wanted to do. I had two webcomic sites already in existence with image-heavy designs and big archives. This was about the retina upgrade path, and I believe what I’ve laid out here is the best way for people who run existing webcomic sites to get up to speed.

In conclusion

I think all online comics will go retina. It’s just a matter of when.

I have hopped on a little early, mostly because of my personal interest in the technology. But if you make a website, you will be forced to join the party eventually!

And given that your archive is only going to grow with time and become harder to convert, it’s best you prepare for this high-resolution future ASAP. At the very least, ensure that your content is ready, and leave the rest to a site redesign.

Together we can all make the web a little sharper. I hope you are inspired by the idea that it’s possible to make a retina-ready webcomic website, even with the handicap of a huge comic archive and visually complicated site design.

Feels good man.

  1. su-itca-se posted this