Yesterday I sat down and implemented a cross-browser (WebKit and Firefox, I don’t count IE) way to achieve a “fade out the element on the right with a mask” effect for our upcoming web app Charm Customer Support—it’s harder than it should be, and here’s how it works:
Fist off, for WebKit-based browsers, the -webkit-mask-image CSS property is used with a CSS gradient. This is really easy to do and straight-forward. However, on Firefox, you need to use a SVG-based gradient that’s piped into the mask CSS property. As far as I know, you can’t just copy+paste the mask property into an external CSS file—if you do that you’ll need to specify the SVG gradient in an external SVG file as well.
While there are relatively few expensive laptops that have a Retina screen, practically all mobile devices have a high density screen. And if you think this is just an Apple-thing, you’re dead wrong—all Android phones and tablets, the Amazon Kindle Fire, the Playbook, and Windows Phones have high-density screens. On the enterprisey side of things, Microsoft announced that Windows 8 will have full support for high-density desktop computers and laptops.
Let’s put this in context: mobile internet usage has doubled last year, and right now about 20% of all web traffic in the US is from mobile devices. This means Retina screens will soon become the norm.
If your websites and apps aren’t Retina-friendly, you’re going to be showing standard definition websites in a high-definition world. It’s not going to be pretty.
I’ve done weeks of research on it and put together the first, definitive guide on the essentials to make your websites and apps shine on high density displays. You can learn all that in just 30 minutes. And it’s out of beta now—updated with the latest and greatest information.
30 minutes to websites and apps that shine on high density displays—in the amount of time it’ll take you to sort through what to read on the web, you could instead read my ebook and be half done with Retinafy-ing your websites already!
An assumption that a lot of web developers have is that retinafying images by doubling their resolution results in files that are four times larger.
The reasoning goes like this: If I take a 100×100 pixel image, that has 10,000 pixels, and has a file size of, for example, 10kb, doubling the resolution to 200×200 means that there are 40,000 pixels now, and the file size must increase to 40kb accordingly.
However, image compression doesn’t work like that—it hardly scales linearly with the amount of pixels in the image.
Let’s look at PNG images first. These are often used for interface elements, logos and so on. There are huge areas of transparency, of single colors and of repetitive color patterns that doesn’t change. Because of that, actual file sizes of images that are twice the resolution of the original don’t differ that much.
For JPEG images, you can just double the resolution (or go as high as possible depending on your original image source), and lower the JPEG quality. Don’t be afraid to go as low as 15 to 25, as shown in these example photos from my Retinafy.me ebook. Yes, on a normal density screen this would cause all sorts of ugly JPEG artifacts—but don’t forget that on a retina screen pixels are so small that you can’t see them, which results in JPEG compression artifacts being far less visible. And when you scale the bigger JPEG image down for display on a normal screen, you get results that rival much higher quality JPEG images at the small resolution.
Note that exceptions prove the rule, and you may end up finding an image which doesn’t compress well or which has visible issues on low quality JPEG settings. For these, I highly recommend spending some time to figure out the root cause and implement workaround (you’ll find information about what to look for in my book!).
Whether the small pixels of retina screens scare you (just kidding!) or you’ll simply don’t want to spend countless hours researching it, my book will be your guide. Step-by-step instructions will show you how to upgrade to high-resolution screens with the least effort. Plus, I’m obsessed about loading speed and image quality.
What’s a Retina screen, and which variations are out there
Why you should use high-resolution images by default
The most efficient way to target retina screens in CSS
How to use CSS and SVG to replace bitmapped user interface elements
Deciding if you need two versions of an image
Creating beautiful favicons that work great on any screen
How to keep file sizes of images in check
And create Retina-ready web sites in no time!
The book also includes easy to follow rules, a decision tree and case studies; as well as detailed comparisons of various quality settings when dealing with high-resolution photos. You’ll also learn how to workaround issues when features are not supported (SVG on Android, hah) and when things are rendered badly.
Right now, the book is in beta and rough around the edges… but you’ll save a cool $10 off the final price if you buy before it’s finalized (the final version should be available in late Summer 2012!).
Update 24/7: If you like the flowchart, grab my ebook on all things Retina at retinafy.me! It’s out in beta now—save $10 over the final price.
With Retina screens all around us, it’s time to take the plunge and retinafy your website or webapp. Here’s the process I use (for both mobile and desktop) in the form of a flowchart for some more sanity in all of this.
Since the announcement of the MacBook Pro with Retina screen, everybody seems to be busy making Retina versions of their sites and apps. Before you @2x everything, let’s take a step back and look at the big picture (*rimshot*). Here are the screen densities of some more or less current Apple products and a current Android phone:
iMac 27″ 109dpi
MacBook Pro 13″ 113dpi
MacBook Pro 15″ Hi-Res 128dpi
iPad 2 132dpi
MacBook Air 11″ 135dpi
MacBook Pro 15″ Retina 220dpi
New iPad 264dpi
Galaxy Nexus 316dpi
iPhone 4 326dpi
What’s not included here is that on the MacBook Pro with the Retina screen you can choose a virtual resolution, and the screen is scaled accordingly.
These virtual resolutions are (afaik) achieved by rendering at twice the virtual resolution and scaling the resulting picture to 2880×1800 (the native resolution of the MacBook Pro’s screen). Let’s have a look at the settings:
1024×640: rendered at 2048×1280, ~156dpi
1280 x 800: rendered at 2560×1600, ~195dpi
1440 x 900: rendered at 2880×1800, 220dpi (native)
1680 x 1050: rendered at 3360×2100, ~257dpi
1920 x 1200: rendered at 3840×2400, ~293dpi
The point is, that if you take all these pixel densities there’s a pretty linear spread. “Just have one normal version and a scaled-by-two version” is just not enough. And this is not only true for Macs and mobile devices, Windows 8 will run at 1x, 1.4x, and 1.8x scaling modes (/ht @thijs).
Plus, on mobile devices people zoom into (and out of) website content all the time and this will likely become the norm on desktop computers, too (Safari already has full support for gesture-based zooming). And there’s the topic of accessibility.
My advice: better do away with ALL raster graphics for your web app or site, and switch to use vector-based artwork (SVG!), possibly custom fonts and of course other CSS3 features where possible. For photos and images, use hi-resolution JPEGs and spend time on optimizing the quality settings.
I recently ported my little CreditCard.js library from Prototype.js to use underscore.js, as I needed that in a project. Here’s what I’ve found—check out the original Prototype.js version first:
And here’s the same thing, but ported to underscore.js:
A few observations that, needless to say, are opinions, not scientific fact:
Prototype.js’ direct extensions of built-in prototypes make code cleaner and easier to read
Some helper functions, like $w are missing in underscore.js
curry is more fun than bind, and I don’t need to specify a scope
These days (actually more like for the last five years), when you’re designing a site and have preview thumbnails/photos/screenshots of things, you’re probably using one of the millions of light box scripts/plugins out there. Light boxes are the new funny mouse trails.
Chances are you’re completely breaking your sites for mobile users.
If you don’t have a mobile site
In case you’re serving the same site to both desktop and mobile users (which for most sites is preferable anyway, Apple does it!), use a light box script that calculates the “center of screen” position once when you open the image. Make sure the button to close the zoomed-in image is always visible.
Don’t use any scripts that recalculate the position on scrolling or window size changes. Users on mobile devices will hate you for it. A lot.
In general, don’t try to be too clever.
If you have a mobile site
The trick is to link to the bigger version of the image directly.
Zappos does it, so you can too.
Addtionally, don’t bother having “retina” versions and “normal” versions. Just provide one single hi-res image.
It’s better to spend your time on seeing what level of JPEG compression works best for the image you use (if you’re curious, Zappos uses 92 for this particular image—one way to find out is to use identify -verbose filename.jpg | grep "Quality" if you have ImageMagick installed).
Plus, have good toolchain to minimize your images without quality loss, I can’t recommend the ImageOptim tool highly enough for that. I was able to shave off a cool 6% of the file size of the image used on Zappos. Your users will love you for the faster loading images!