Thomas Fuchs
Hi, I'm Thomas Fuchs. I'm the author of Zepto.js, of, and I'm a Ruby on Rails core alumnus. With Amy Hoy I'm building cheerful software, like Noko Time Tracking and Every Time Zone and write books like
   Want me to speak at your conference? Contact me!

Masking HTML elements with gradient-based fadeouts

September 16th, 2012

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.

Anyway, here’s how it looks like:

Bacon ipsum dolor sit amet pig capicola flank drumstick tri-tip cow pork. Tenderloin pork belly ham cow chuck strip steak andouille fatback beef ribs. Tongue jowl pig chicken flank drumstick pancetta strip steak capicola biltong. Swine jowl beef ribs filet mignon spare ribs, beef bresaola tail venison pork loin pancetta prosciutto meatloaf fatback turkey. Bresaola turducken beef ribs ribeye salami chicken hamburger meatloaf. T-bone spare ribs rump, strip steak tongue sirloin biltong capicola corned beef bresaola. Swine ham tail filet mignon t-bone flank.

And for future reference, here’s the code for it:

If anyone knows a way to make this work with IE, I’m happy to add it to this post (just fork the gist!).

Pragmatic.js—A pragmatic style guide to JavaScript

September 13th, 2012

JavaScript is a modern, flexible and malleable scripting language, and it deserves to be treated as such—to this extend, I’ve extracted the style guide Mislav and I wrote for Zepto in a new project called Pragmatic.js.

There are a lot of style guides out there, but they are all a long and tedious read and, in my opinion, often read like people are scared of using JavaScript and want to make it look more like C or Java. But it’s not. It’s a super awesome scripting language with lots of wonderful features (and arguably some quirks as well!).

Writing pragmatic JavaScript is all about optimizing the process of writing JavaScript for you as a programmer, using all the facilities the language provides.

Read more (and feel free to contribute!) at the Pragmatic.js GitHub repository.

Is Learning to Make Your Website or App Retina-friendly Worth Your Time?

September 11th, 2012

Retinafy your web sites and apps! Grab my new ebook, now available!

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!

Learn more about the Retinafy ebook and grab your copy now!

P.S. As a reader of yours truly, you’ll get a $5 off coupon—hurry and use code MIRACULOUS, this code will expire on September 15! 🙂

High resolution images and file size

August 6th, 2012

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 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!).

These examples are straight from my Retinafy your web sites & apps ebook. Don’t let the pixels win! Grab a copy, learn all the tricks in a quick read, and save $10 over the final price while it’s in beta!

Never look pixelated again

July 24th, 2012

I’m super-excited to introduce my new ebook Retinafy your web sites & apps to you. It’s out now in beta!

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.

Learn about…

  • 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
  • Why JavaScript-based image replacement techniques are a bad idea

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!).

Head over to to grab your copy!

Flowchart: how to retinafy your website

June 26th, 2012
Update 24/7: If you like the flowchart, grab my ebook on all things Retina at! 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.

Download as PDF (968k)

The result of this? Amazing looking stuff, like our very own Charm Customer Support app (coming soon!).

More than meets the eye

June 14th, 2012

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.

Prototype.js vs. underscore.js showdown

June 7th, 2012

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
  • Sometimes JavaScript-provided APIs like reduce have their arguments in just the wrong order; especially when used with chained method calls.
  • 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
  • Porting is pretty straight-forward, a testament to Prototype.js’ influential role in modern JavaScript

Prototype.js is still awesomesauce, and in many ways the mother of modern JavaScript libraries. I still prefer the syntax over many of the newer libraries. These newer libs have their own advantages, of course, mainly size and modularity. But sometimes I do long for the good old times.

Want to learn how to master JavaScript? Grab a seat at the JavaScript Master Class, a two half-day live online class with Amy Hoy and yours truly! (Next date: June 14/15, 2012!)

5 compelling reasons why to use semicolons in JavaScript

June 4th, 2012

The trouble with light boxes

May 17th, 2012

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.

Why? First off, it loads really fast, as only the image has to be transferred and you won’t need any JavaScript at all. Secondly, the user can use gestures to zoom in on the image and by default it’s shown as full-screen as possible. Afterwards the user can just hit the back button to go back to your main content. There’s no need to implement fancy zoom scripts and complicated UI controls; the user already knows how to zoom images on the device.

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!

Want to learn how to master JavaScript? Grab a seat at the JavaScript Master Class, a two half-day live online class with Amy Hoy and yours truly! (Next date: June 14/15, 2012!)