Towards a Retina Web: Follow-up

Last week I wrote a lengthy article over at Smashing Magazine covering different techniques to prepare websites and web apps for Retina devices. The feedback has been overwhelmingly good, but it also highlighted an apparent divide in the web design and development community over the why and the how of this transition.

Several commenters have argued that optimizing for Retina is unnecessary given the insignificant market share of HiDPI devices; that is simply beside the point. Those who are not convinced that offering a superior experience to a growing portion of their user base is worthwhile are clearly not the target audience.

TLDR

The first section of the article attempts to clear out some of the confusion surrounding the difference between device, CSS, and bitmap pixels, while the second goes over the different approaches to serve high resolution images to Retina devices, namely:

• HTML/CSS sizing: a straightforward solution that consists in using images with a bitmap resolution that is exactly double their CSS target size. Generally speaking, this approach is not bandwidth-friendly and should be avoided in most cases.

• CSS/JS media querying: currently the most popular approach given its flexibility and bandwidth efficiency (serves only one asset per device). Its main shortcoming is the often tedious multiple-asset workflow (separate files for each media query).

• SVG: the vector graphic format of the web. Ideal for icons, logos, and simple graphics. SVG works best with a PNG fallback for older browsers.

• Icon fonts: consists in serving resolution-independent icons using @font-face with a custom web font. The lack of pixel-level control and editability are easily made up for with more flexibility and ease of use.

Live Examples

Following the suggestion of some readers, I put together a live examples page showcasing most of the techniques covered in the article. The page is comprised of two sets of examples, each yielding the same crisp results regardless of the screen density. Feel free to refer to it for a quick fix, and make sure to keep an eye on the repo for updates.

Javascript Libraries

The primary goal of the article was to introduce plugin-free, client-side approaches to get started with resolution-agnostic web design. If you have been longing for a comprehensive list of JS libraries (both client and server side) for serving responsive images, look no further than this comparison chart put together by Boris Smus.

Sass Mixin

The newly introduced content blocks in Sass 3.2 make it extremely easy to use CSS querying without having to worry about the math or the verbose syntax. Enter the retina() mixin:

@mixin retina($ratio: 1.3) {
  @media only screen and (-webkit-min-device-pixel-ratio: $ratio),
  only screen and (min--moz-device-pixel-ratio: $ratio),
  only screen and (-o-min-device-pixel-ratio: ($ratio*10)/10),
  only screen and (min-resolution: #{round($ratio*96)}dpi),
  only screen and (min-resolution: #{$ratio}dppx) {
    @content;
  }
}

The default ratio of 1.3 is meant to include Google Nexus 7 in the query, as Marc Edwards reports. I also intentionally left out the un-prefixed min-device-pixel-ratio since as it stands now, there seems to be little prospects of it being standardized. Meanwhile, the future-proof min-resolution seems to have a wider browser support and is more likely to replace Webkit’s device-pixel-ratio once the transition from inches (dpi) to pixels (ddpx) is complete.

Take Action

Everyone would agree that none of the currently available solutions is striking a good balance between graphic crispness, ease of implementation, loading speed and cross-browser compatibility. And as many readers pointed out, it is going to take a while before we get anywhere close to that.

In the meantime, here some are immediately actionable items that would make this transition much less painful:

• Replace your PNG icons with SVG when appropriate. Use PNG fallbacks if you care about the pre-IE9 crowd. You may use icon fonts as well if you can live with less pixel-level control.

• Prepare @2x versions of prominent images in your website or app (splash screens, backgrounds, patterns, etc.) and use CSS or JS querying to swap them in on HiDPI devices. For inline images, your best bet for now is to use one of the available JS libraries.

• Use CSS as much as possible for typography and UI elements. CSS3 is in the process of obsoleting Photoshop, and for a good reason.

While it may sound unreasonable—especially in a business context—to do all this “extra” work for every design project, you’d be surprised at how these practices make you much more efficient and improve your overall design workflow.

Style Sheet Swag: architecting your applications styles

Aside from applying that killer layout and visual design to your project, stylesheets need to be organized in a way that effectively communicates markup and style relationships and allows for quick and easy modification. A good measure of a well architected front-end is how easy it is for a new team member to jump into your project or for a new team to it take over. If your methods for organization and selector naming aren’t consistent and easily communicated to or understood by others, you’re probably creating a lot of code debt and certainly creating a higher than necessary barrier to entry for newcomers to the project.

This is how we do it.

Thanks to the partials feature in css preprocessors like Sass, less.js, and Stylus, we can organize our stylesheets better than ever before. We work with Sass because it comes built into rails and it’s awesome.

From the very start, all the apps we build come with a gem we built called Flutie. Flutie provides a stylesheet reset and most importantly, a method that adds a class name to the body element of every page. The body class name is made from the name of the controller and action responsible for generating that page. This allows us to target specific pages by using the unique body class and it also helps us semantically model our stylesheets directory after our views directory. So if we have a Clips controller with an Edit action and we have an associated view for that action called edit.html.erb in views/clips/ then the body element in that view would get a class of .clips clips-edit and in our stylesheets directory we should create a sass partial called _clips_edit.scss, if we are going to be applying styles to that view. Instead of namespacing the .scss files you could group your style sheets in folders (ex: clips/_edit.scss) the same way the rails views are organized. Organizing your styles in this way makes it much easier to find the styles you’re looking for when working between the browser’s inspector and your text editor.

Variables, Mixins, Extends, etc.

So what about all the variables, mixins, extends, and other great stuff you can do with Sass and most other preprocessors, where do they go? We have found that organizing our variables, extends, mixins, animations and general base styles (default styles for things like typography, links, etc) in partials to be very useful. These partials are usually namespaced with _base or kept in a folder base/. So in a typical project I will have _base.scss, _base_variables.scss, _base_mixins.scss etc.

Shared components

Often times we will build components of an application to be modular. So to keep the styles for these components modular as well, we create “shared” partials. If in your application you have a header component that maintains all or the majority of its styles across multiple views in your app, create a partial called _shared_header.scss or put _header.scss into a “shared” folder. If you have a view, clips_index.html.erb for example, in your app that is sharing the header with another view (clips_edit.html.erb lets say) but needs a slight tweak, target the header component in the _clips_index.scss stylesheet partial and make the clips_index.html.erb view specific tweaks there.

Generating the css

Now that we have our styles logically organized we create a file, often called application.scss or screen.scss, in which we import all of our partials with the @import directive (ex: @import “clips_edit.scss”;) to render the single stylesheet our app will use. The order in which you import these files is important as the import will render the contents of the imported files in the order they are imported and these are cascading styles sheets after all, so make sure you are importing your variables and base styles at the top.

Stay Fresh

As a consulting shop, one of our goals is to deliver clean code that our clients can continue to easily work with and grow after we are done working on the project. From the front-end perspective, an important piece of making that happen is keeping our markup and styles clearly organized by constantly using agreed upon methods. All code should look like it was written by one person, regardless of the actual number of contributors. Trying to work in a large application that has no clear reasoning for the structure of its front-end can feel like battling a kraken with a countless number of limbs. So even if you will be the only person ever working on a project, your future self will certainly appreciate the efforts you make now to keep your styles organized, modular and easily modified.

Hidden Secrets of the Chrome Developer Tools

In case you haven’t seen it yet, on Monday we posted our latest screencast, Hidden Secrets of the Chrome Developer Tools.

Ben was inspired to create this screencast when a coworker blew his mind by investigating a problem with the javascript debugger. He’d been using Chrome and the Dev Tools for over a year, but had no idea what he was missing. Rather than continuing to learn things when someone nonchalantly used a feature, he decided to discover everything all at once. This screencast is packed with everything he wished someone had shown him when he first started using Chrome.

The goal of this screencast isn’t to show you everything that the Dev Tools can do, but instead, to focus on the most useful parts of them, and the parts people tend not to know about.

Watch a quick preview:

As with all of our education products, you can buy it now for both yourself or your entire company.