Luxagraf

Scaling Responsive Images in CSS

Thu, 27 Feb 2014 11:56:00 EST

It’s pretty easy to handle images responsively with CSS. Just use @media queries to swap images at various breakpoints in your design.

It’s slightly trickier to get those images to be fluid and scale in between breakpoints. Or rather, it’s not hard to get them to scale horizontally, but what about vertical scaling?

Imagine this scenario. You have a div with a paragraph inside it and you want to add a background using the :before pseudo element — just a decorative image behind some text. You can set the max-width to 100% to get the image to fluidly scale in width, but what about scaling the height?

That’s a bit trickier, or at least it tripped me up for a minute the other day. I started with this:

.wrapper--image:before {
    content: "";
    display: block;
    max-width: 100%;
    height: 443px;
    background-color: #f3f;
    background-image: url('bg.jpg');
    background-repeat: no-repeat;
    background-size: 100%;
 }

Do that and you’ll see… nothing. Okay, I expected that. Setting height to auto doesn’t work because the pseudo element has no real content, which means its default height is zero. Okay, how do I fix that?

You might try setting the height to the height of your background image. That works whenever the div is the size of, or larger than, the image. But the minute your image scales down at all you’ll have blank space at the bottom of your div, because the div has a fixed height with an image inside that’s shorter than that fixed height. Try re-sizing this demo to see what I’m talking about, make the window less than 800px and you’ll see the box no longer scales with the image.

To get around this we can borrow a trick from Thierry Koblentz’s technique for creating intrinsic ratios for video to create a box that maintains the ratio of our background image.

We’ll leave everything the way it is, but add one line:

.wrapper--image:before {
    content: "";
    display: block;
    max-width: 100%;
    background-color: #f3f;
    background-image: url('bg.jpg');
    background-repeat: no-repeat;
    background-size: 100%;
    padding-top: 55.375%;
}

We’ve added padding to the top of the element, which forces the element to have a height (at least visually). But where did I get that number? That’s the ratio of the dimensions of the background image. I simply divided the height of the image by the width of the image. In this case my image was 443px tall and 800px wide, which gives us 53.375%.

Here’s a working demo.

And there you have it, properly scaling CSS background images on :before or other “empty” elements, pseudo or otherwise.

The only real problem with this technique is that requires you to know the dimensions of your image ahead of time. That won’t be possible in every scenario, but if it is, this will work.

Live Editing Sass in Firefox with Vim Keybindings

Thu, 20 Feb 2014 10:08:00 EST

The Firefox developer tools now support live editing Sass files right in the browser.

This is, like a lot of what Mozilla has been doing lately, a case of Firefox playing catch-up with the competition — Chrome has had similar features for quite some time.

On the other hand, Firefox is ahead of Chrome in another area: Vim and Emacs keybindings (which I believe is because the editor in Firefox is based on CodeMirror).

If that means nothing to you then stick with Chrome. If, however, you’re loath to abandon the power of Vim or Emacs for editing files in the browser, this means you can have the best of both worlds — live editing Sass files in the browser and Vim or Emacs keybindings.

Because live editing Sass files in the browser with Vim keybindings? That’s some awesome sauce right there.

If you prefer, here’s a screencast walking you through the process. Other wise, read on.

Set Up Sass Editing in Firefox.

The Mozilla Hacks blog posted a quick overview on how to set things up, but it assumes you’ve already got Sass set up to compile sourcemaps. In case you don’t, here’s some more complete instructions on how to set up Sass and Firefox¹.

Firefox

First off you need a pre-release version of Firefox. Both the Sass sourcemaps support and the Vim/Emacs keybindings are available starting with Firefox 29. I use the Nightly channel (currently Firefox 30a1), but the Aurora channel (currently Firefox 29a2) will work as well.

Sass and Compass

The next step is to set up Sass such that it will output a sourcemap file in addition to your CSS.

What in the world is a sourcemap? Simply put, sourcemaps are a way to map compiled code back to its pre-compiled source. The reason any of this is possible at all is because Sass recently added support for CSS sourcemaps. That means that when it turns your Sass code into CSS, Sass also outputs a map of what it did. Firefox can then look at the map and connect the rendered CSS back to your source Sass. The sourcemap support is brand new and currently only found in the pre-release versions of Sass.

I happen to like the Sass offshoot Compass better than vanilla Sass as Compass provides some very handy extras like CSS 3 prefixing tools. As with Sass, only the pre-release versions of Compass support sourcemaps (and even those are not quite there).

Fortunately we can get the pre-release versions of both Sass and Compass with a single command.

$ sudo gem install compass --pre

This command tells the Ruby gem system that we want the pre-release version of Compass (that’s what the —pre flag is for). In the process we’ll also get the latest version of Sass that works with Compass.

You’re probably used to starting Compass with something like compass watch. Eventually you’ll be able to do that, but for now the only way I’ve been able to get Sass, Compass and sourcemaps working together is by invoking sass directly like so:

`sass --compass --poll --sourcemap --watch sass/screen.scss:screen.css`

To break that down:

sass --compass — this bit starts Sass and includes Compass so that we have access to all our extras.
--poll — this gets around a super annoying permissions error. This shouldn’t be necessary, but currently it gets around a bug. Alternately you can start sass with sudo.
--watch — watch tells sass to watch for changes rather than just compiling once.
--sourcemap sass/screen.scss:screen.css — This is the important part. We tell Sass that we want to use sourcemaps and then we create a mapping. In this case I’ve told Sass to make a map explaining how the file screen.scss inside the sass folder turns into the screen.css output file. This is what Firefox will use to map CSS rules to Sass rules.

Sass is now running, watching our files for changes. Now we just need a local server of some kind. I typically use my my python server trick for quick prototyping, but anything will work — local Apache, Nginx, Django development server, whatever development server RoR offers — anything will work.

Putting it All Together

Now let’s go back to Firefox and let it know about our sourcemap.

Here’s where things are significantly different than Chrome. I’m not sure which is “better” but if you’re used to the Chrome approach, the Firefox approach may seem strange.

First load your localhost url. Now open the developer tools and inspect some element you want to change. Now all you need to do is right click in the CSS section of the Inspector tab and choose “Show original sources”. Now click the little link next to the style rules and Firefox will open your Sass file in the Style editor.

Now just hit save, either the link next to the file list or hit CMD-S (CTRL-S). The first time you save a file you have to tell Firefox where the file is on your disk — navigate to the folder with your Sass files and hit save, overwriting the original. You’ll need to do this once for each Sass partial that you have, which is annoying if you’ve got a lot. I happen to prefer the Chrome method, which maps the local folder to a local URL. It’s a bit more work to set up, but you only have to do it once.

Either way though that’s it, you’re done. Edit Sass live in the browser, see your changes update almost instantly with no refresh.

Here’s what it looks like:

Just right click to change the view from compiled CSS to SCSS. Pretty Cool. Note that I’ve already saved the file once so Firefox knows where it is.

Vim or Emacs Keybindings

I know, I know you were only in it for the keybindings, how the heck do you get those?

Pretty simple. Open about:config and search for devtools.editor.keymap. Right click the “value” field and enter either “vim” or “emacs”. I had to restart Firefox for the changes to take effect.

Now you have a way to edit Sass right in the browser and still get the benefit of all the keyboard shortcuts you’ve commited to muscle memory over the years.

There’s one annoying bug (at least I think it’s a bug) for Vim users, :w (the Vim save command) does not work like CMD-S (CTRL-S); it will always open the file save dialog box rather than just writing to disk. It’s annoying, but I haven’t found a workaround yet.

Shortcomings Compared to Chrome

While Firefox’s combo of live editing Sass and Vim keybindings is awesome, there a couple things that I think could be improved.

In Chrome if you CMD-click (or CTRL-click) on an individual CSS rule in the styles tab Chrome jumps you to the relevant file and moves your cursor right to that rule. It even highlights the line in yellow for a second or two so you know where the cursor is in the file. It’s very slick and very useful. CMD-click a rule in Firefox and nothing special will happen. Bummer.

The other thing that’s troubling me with Firefox is the need to “Save As” the first time you edit a Sass file. It feels janky to me and frankly it’s a pain when your project has dozens and dozens of Sass partials. I much prefer Chrome’s (admittedly perhaps more confusing at first) approach of associating a folder with a URL.

Still, the Vim keybindings makes me more productive than I can be in Chrome without them so I’m back to Firefox.

A Complete Guide to the `` Element

Wed, 19 Feb 2014 09:30:00 EST

If you’ve ever struggled building responsive websites, this post is for you. It’s part of a series on responsive design, in particular responsive images, pulled from my book, Responsive Web Design. If you find this excerpt useful, and want even more ideas on how responsive design can help you create amazing websites, pick up a copy today.

Most people who’ve never heard the phrase before think that “responsive design” refers to building websites that are, well, responsive. That is, fast pages that respond to user input with no lag or discernable load times.

Of course that’s not exactly what the phrase “responsive design” refers to in most web development contexts, but I think the web might be better off if it were. I don’t think we need to throw out Ethan Marcotte’s original definition of responsive design — fluid grids, flexible images and @media queries — but perhaps we could add another criteria to our definition: responsive websites should, above all else, be really, really fast.

There are many, many ways to speed up websites, responsive or otherwise, but few things will lighten the load like reducing image size. If you’ve done nothing yet to optimize the front-end portion of your site, images are almost always the best place to start.

Unfortunately there really is no Platonic ideal for serving up responsive images. My favorite “works today” solution is Matt Wilcox’s Adaptive Images but it doesn’t work in every scenario, nor does it handle all the possible use cases for responsive images.

A real responsive images solution is going to take more than clever coding. It’s going to have to involve web browsers, web standards bodies and web developers.

Luckily for developers like you and me, browser makers, the W3C and some very smart web developers have been working on the problem of how to serve the right images to the right device for several years now. So far there have been three big proposals, one of which I’ve covered before in Responsive Images & srcset (it appears that srcset may still become part of <img>).

The other two major proposals have since merged to become what will likely be the best responsive images solution in the future: the proposed <picture> element.

The `<picture>` Element

Following the development of <picture> has been like listening to Statler and Waldorf in the balcony of the Muppet’s theatre: “I love it!” “It’s terrible!” “It’s brilliant!” “It’s okay” “It could be better” “It’s awful!” “I love it!” And so on as developers and browser makers hashed out the details.

As of this writing the general consensus seems to be coalescing somewhere around “I love it!” and “It could be better”.

On a practical level — which is to say, are browsers going to support it? — <picture>‘s future is looking pretty good. It’s on Mozilla’s informal roadmap for Q1 of 2014 and the Chromium dev team has started work on support for <picture> (which means it will be in Opera as well). Apple’s WebKit team appears to like the current implementations, though it has yet to commit to anything. The Internet Explorer team, well, who knows? Is there even still an IE team?

The good news is that <picture> degrades gracefully to a good old <img> tag, so older browsers will still display whatever you use for a fallback.

That said, because the spec is barely even at the draft stage, what follows is theory, not cut and paste code. There is no browser support for this. There isn’t even a modified version of Chromium you can test it in¹.

Worse, the specifics of <picture> may well change (if they do I’ll update this post) so don’t go dropping it into your pages just yet. This tutorial is meant to give you an overview of how <picture> will work, not provide code you can use today. You’ve been warned.

Awesome Sauce! Gimme Some `<picture>`

For better or worse <picture> follows, at least partly, in the footsteps of <audio> and <video>, acting as a container element for <source> elements which then point to the actual images you want to load. The browser evaluates all the various attributes you’ve specified, picks the best image and then loads the image into the <img> inside your <picture> tag. In other words, <picture> doesn’t actually display your image, it just tells the browser which image to display.

To help the browser pick the best image you have three major components to work with, all attributes of <source> elements within the <picture> tag.

The three attributes are:

srcset: Yes, the same srcset that was originally proposed for the <img> tag. The srcset attribute gives the browser a list of possible images, along with some (optional) “hints” about the screen resolution and screen size that correspond with each image source.
media: The media attribute is where you would put your @media query information. When the @media attribute evaluates to true, the browser then moves to the associated srcset.
sizes: The sizes attribute allows you to specify a set of intrinsic sizes for the images described in the srcset attribute. This one is a little tricky at first, but basically it allows you to tell the browser how much of the viewport should be taken up by the image. This will become clearer in the example below.

To get a better understanding of how each attribute works, let’s dive into some code.

Using the `<picture>` Element for High Resolution Images

Let’s start with the first use case in the responsive images use case list: “resolution-based selection“. Essentially we want to serve high-resolution images to high-res devices while allowing low-res devices to avoid the bandwidth penalty of overly-large files.

Here’s how you would use <picture> to give Retina screens high-res images and regular screens regular images.

Let’s say we’re trying to build a more responsive version of the LongHandPixel’s bookstore. Assuming we have two book cover images for each book — cover1x.jpg, which is a normal resolution image and cover2x.jpg which is the same image, but at a much higher resolution. Let’s go ahead and make things future-friendly by adding a third image, cover4x.jpg, to handle those 4K+ monitors that are just a few years away from being on every desktop. So with three images at three resolutions our <picture> code would look like this:

<picture>
    <source srcset="cover1x.jpg 1x, cover2x.jpg 2x, cover4x.jpg 4x">
    <img src="cover1x.jpg" alt="Responsive Web Design cover">
</picture>

Here we have a simple <picture> tag with one <source> tag and an <img> tag which doubles as a fall back for older browsers. Within the <source> tag we’ve used the srcset attribute to say to the browser (or “user-agent” in spec-speak) if the screen pixel density is 1x then load cover1x.jpg; if the screen density is 2x then load the higher-resolution cover2x.jpg. Finally, if the screen density is 4x, grab cover4x.jpg.

What happens if the resolution is somewhere in between these values? Well, you could add in other resolutions (e.g. 1.3x, 1.6x and so on) and URLs if you want to be explicit. Remember though that which image to choose is entirely up to the browser. The srcset values we’ve given are described in the spec as “hints”. It may be that, despite having a high-res screen, the user has explicitly instructed the browser (through a preference setting) not to download large images over 3G.

Screen resolution is after all just one factor in deciding on the appropriate image to download. As developers we don’t (and never will) have all the information that the browser does, which is why the final decision lies with the browser. As I’ve said before, this is a good thing; this is exactly the way it should be.

That’s how you would handle the simple resolution-based selection scenario. Before we move on though, let’s look at another value you can add to srcset declarations: width.

Consider this scenario: we have roughly the same situation, we’ll limit it to two images this time, one high-res, one not. But we don’t know how wide the image is going to be on the user’s screen. Say our normal-res image is 640px wide. On a high-res screen that happens to be only 320 effective pixels wide, a 640px image would actually qualify as a high-res image. The situation is slightly more nuanced than a simple 1x vs 2x screen. To always send the larger image to 2x screens might still waste bandwidth because we’re not accounting for the size of the screen/image.

Here’s how you can handle this scenario with <picture>. Let’s stick with the same assumptions in the last scenario, but let’s be a little more specific this time, cover1x.jpg is 640px wide and cover2x.jpg is 1280px wide. Here’s what the code would look like:

<picture>
    <source sizes="100%" srcset="cover1x.jpg 640w, cover2x.jpg 1280w">
    <img src="cover1x.jpg" alt="Responsive Web Design cover">
</picture>

Now our srcset values are based on width and the browser gets to select the best image based on another <source> attribute, sizes. In this case we’ve told the browser that final image selected will be as wide as the entire viewport. Later we’ll see how you can use this with other values.

The final result will be as wide as the viewport, so if the user is on a device that is effectively 320px wide, but at 2x density the browser would, barring other conflicting info like user settings, pick cover1.jpg. If the user’s viewport happened to be 640px wide, but the density was only 1x, cover1.jpg would again be used. On the other hand if the viewport happened to be 640px wide, but the density was 2x, cover2.jpg would be used.

Different Image Sizes Based on Viewport Width

When you think of responsive images, this is probably the use case you think of — serving smaller images to smaller screens, larger ones to larger screens. Later we’ll see how you can combine this with the pixel density stuff above for even more control.

First, here’s how <picture> can be used to serve up different images based on viewport width.

For the following examples, let’s say we have three images, small.jpg, medium.jpg and large.jpg and we want to serve them to the corresponding viewport sizes. Let’s make one more assumption: that we’re taking a mobile-first approach and our fallback will also be the smallest image.

Here’s what that code would look like:

<picture>
    <source media="(min-width: 45em)" srcset="large.jpg">
    <source media="(min-width: 18em)" srcset="medium.jpg">
    <img src="small.jpg" alt="Robert Anton Wilson laughing">
</picture>

This time we’ve used the media attribute to write a couple queries that work just like CSS @media queries. Our mobile-first approach here means any viewport larger than 45em gets large.jpg, any viewport between 18em and 45em gets medium.jpg and anything smaller than 18em gets our small.jpg.

Notice that here our smaller image is in the <img> tag, not a <source> tag. While we could add a third <source> tag with a srcset pointing to small.jpg, there’s no need to do that since, as I mentioned earlier, <picture> and <source> are not the tags that actually load images. The <picture> element must contain an <img> element for the browser to actually display your image. Browsers that understand <picture> will first parse through all your rules, pick an image and then swap that image into the src attribute on the <img> tag.

In this example not only is the <img> tag a fallback for older browsers, its src value also becomes the image used by <picture> savvy browsers if neither media query evaluates to true.

Different Image Size and Resolution Based on Viewport Width

Now let’s combine both of the previous examples and use <picture> to serve up different size and resolution images based on viewport width and device pixel density. To do that we’ll need six images — small.jpg, small-hd.jpg, medium.jpg, medium-hd.jpg, .large.jpg and large-hd.jpg (side note: in the future you’ll want a CMS that’s good at generating tons of image options from the one you actually upload. Otherwise, plan on going insane while resizing images in Photoshop).

Okay, let’s put all those images into a <picture> tag:

<picture>
    <source media="(min-width: 45em)" srcset="large.jpg, large-hd.jpg 2x">
    <source media="(min-width: 18em)" srcset="medium.jpg, medium-hd.jpg 2x">
    <source srcset="small.jpg, small-hd.jpg 2x">
    <img src="small.jpg" alt="Robert Anton Wilson laughing" >
</picture>

This looks just like the previous example except that now our scrset includes a second image and the 2x value to indicate that our -hd.jpg images are for high resolution screens.

Also note that this time we did use a third <source> tag since small screen devices may still be high resolution. That is, while we don’t need a media attribute, we do want to check the resolution, which requires a third <source> tag.

Solving the Art Direction Conundrum

Here’s a common responsive design problem: You have an image that, at full size on large screens, easily conveys its information. However, when that image is scaled down to fit on a small screen it becomes difficult to understand the image. For example consider an image of the president shaking hands with Robert Anton Wilson. At full size the image might show both men and some background, but when shrunk down you would barely be able to make out that it’s two men shaking hands, let alone have any clue who the men might be.

In situations like this it makes sense to crop the image rather than just scaling it down. In the example above that might mean cropping the image to be just the President and Robert Anton Wilson’s heads. You no longer know they’re shaking hands, but most of the time it’s more important to know who they are than what they’re doing.

Frankly, handling this scenario is really more a problem for your CMS than the <picture> element. But assuming you have a way to generate the cropped image (or images if you’re doing both normal and high-res) then the code would look something like this:

<picture>
    <source media="(min-width: 45em)" srcset="original.jpg, original-hd.jpg 2x">
    <source media="(min-width: 18em)" srcset="cropped-medium.jpg, cropped-medium-hd.jpg 2x">
    <source srcset="cropped-small.jpg, cropped-small-hd.jpg 2x">
    <img src="cropped-small.jpg" alt="The President shaking hands with Robert Anton Wilson" >
</picture>

Here we’re assuming there are two crops that make sense for the viewports they’re targeting. In this case that means a crop that fits viewports between 18em and 45em and another (presumably tighter) crop for smaller screens. We’re also assuming we have both regular and high-resolution versions of the image.

See what I mean about having a CMS that makes it really easy to generate a ton of different images from a single source? Having to do something like this by hand would suck for even the smallest of blogs.

There are other possible scenarios that fit the art direction problem, for example, providing a black and white version of a color pie chart for monochrome screens.

Handling More Complex Scenarios

So far we’ve looked at pretty easy-to-grok scenarios using <picture>, but the new element addresses some more complex situations as well. For example, we might have a responsive layout where images morph depending on viewport width (and thus there may not always be a one-to-one correlation between viewport width and image size).

The <picture> element can handle this scenario as well, but this where the syntax starts to get, well, things can get complicated (as things tend to do when you want them to be very flexible).

Imagine you have a storefront with three breakpoints, one for phone-ish devices, another for tablet-ish and a desktop layout. You build the site using a mobile-first approach, so you start with a single-column layout with images that span the full width of the viewport. At the first breakpoint the images switch to a two-column layout and may be a bit smaller than the full-width, single-column images just before the breakpoint (even though the viewport is larger now). Finally, on the larger layout the images move to a three-column grid and start off at the same size as the two-column layout but then scale up to be as large or larger than the images in the single-column layout.

The very common image grid scenario. In this example we’re using a single column (100% width) on small screens, two columns (50% width) on medium screens and three columns (rough 33%, but with some additional padding) on large screens.

So what do we do with this scenario? Again, the first thing you’ll need is a CMS that generates, let’s say six, images to fit this scenario. Assuming the images are in place, the code is actually not that bad, albeit a little verbose. Here’s some example code pulled directly from the responsive images spec:

<picture>
<source sizes="(max-width: 30em) 100%, (max-width: 50em) 50%, calc(33% - 100px)"
        srcset="pic100.jpg 100w, pic200.jpg 200w, pic400.jpg 400w,
                pic800.jpg 800w, pic1600.jpg 1600w, pic3200.jpg 3200w">
<img src="pic400.jpg" alt="Robert Anton Wilson laughing">
</picture>

Believe it or not, this is actually the terse way to write this out. You could write this out as six different <source> elements each with the entire srcset above, though I have no idea why you would want to do that.

Let’s step through the code line by line. The first thing we do is set up a series of breakpoints along with the size of the image relative to the viewport width at each of those breakpoints. So (max-width: 30em) 100% covers our smaller screen where the layout is single column and the image is full width. Then (max-width: 50em) 50% covers our medium layout which happens between 30em and 50em, where images are now 50% the width of the viewport.

For the last argument in sizes things are a little trickier. There’s no max-width, this just applies to everything over 50em. The single argument uses calc() to say images are 1/3 the viewport width, but there’s 100px of padding as well. You may have heard that you should avoid using calc() in CSS since it tends to slow things down. Is the same thing true here? I actually don’t know; if you do, chime in in the comments.

Once we have the image-to-viewport ratio setup for each of our layout possibilities, then we use srcset to point the browser to our six image sizes, adding a width specification to help the browser pick the best one. In the end the browser will pick the optimal image based on the current image-to-viewport ratio, current viewport size and current viewport density.

Complicated though this may be, it’s actually pretty awesome. You’ve got the ability to serve the right image to the right screen based on the actual size the image will be on the screen. That’s far more effective and powerful than just saying send a small image to a small screen and a big on to a big screen.

Super Awesome Sauce! Gimme Some.

No. No <picture> for you.

Not yet anyway. No browser supports this, though as noted Chromium and Firefox are both working on support. There’s also no polyfill for this version of <picture>, though there should be one soon.

To make things a little more confusing there is a polyfill for an older version of <picture>. Picturefill is Scott Jehl’s clever way to bring the <picture> tag concept to the web today. The problem with Picturefill is that so far it hasn’t been updated to reflect the most recent improvements to <picture>.

Fear not though, there’s already an open issue on the Picturefill GitHub page. Mat “picture-ninja” Marquis says “this third version of the picture proposal is going out for review by some of the major players very soon, so I’m thinking it might be best if we wait until after any feedback comes back—then we can rework the Prollyfill branch per the spec.” In other words, Picturefill will likely be updated pretty soon.

In the mean time, every time you get frustrated hacking at some kind of responsive images solution just pull up the <picture> spec page and admire the simplicity that will, if all goes well, be taken for granted within a few years.

There is a special build of Chromium that supports an older version of the <picture> proposal, but as of today it doesn’t handle the new version. ↩

Install Nginx on Debian/Ubuntu

Mon, 10 Feb 2014 11:35:00 EST

I recently helped a friend set up his first Nginx server and in the process realized I didn’t have a good working reference for how I set up Nginx.

So, for myself, my friend and anyone else looking to get started with Nginx, here’s my somewhat opinionated guide to installing and configuring Nginx to serve static files. Which is to say, this is how I install and set up Nginx to serve my own and my clients’ static files whether those files are simply stylesheets, images and JavaScript or full static sites like this one. What follows is what I believe are the best practices of Nginx¹; if you know better, please correct me in the comments.

Nginx Beats Apache for Static Content²

I’ve written before about how static website generators like Jekyll, Pelican and Cactus are a great way to prototype websites in a hurry. They’re also great tools for actually managing sites, not just “blogs”. There are in fact some very large websites powered by these “blogging” engines. President Obama’s very successful fundraising website ran on Jekyll.

Whether you’re just building a quick live prototype or running an actual live website of static files, you’ll need a good server. So why not use Apache? Simply put, Apache is overkill.

Unlike Apache, which is a jack-of-all-trades server, Nginx was really designed to do just a few things well, one of which is to offer a simple, fast, lightweight server for static files. And Nginx is really, really good at serving static files. In fact, in my experience Nginx with PageSpeed, gzip, far future expires headers and a couple other extras I’ll mention is faster than serving static files from Amazon S3³ (potentially even faster in the future if Verizon and its ilk really do start throttling cloud-based services).

Nginx is Different from Apache

In its quest to be lightweight and fast, Nginx takes a different approach to modules than you’re probably familiar with in Apache. In Apache you can dynamically load various features using modules. You just add something like LoadModule alias_module modules/mod_alias.so to your Apache config files and just like that Apache loads the alias module.

Unlike Apache, Nginx can not dynamically load modules. Nginx has available what it has available when you install it.

That means if you really want to customize and tweak it, it’s best to install Nginx from source. You don’t have to install it from source. But if you really want a screaming fast server, I suggest compiling Nginx yourself, enabling and disabling exactly the modules you need. Installing Nginx from source allows you to add some third-party tools, most notably Google’s PageSpeed module, which has some fantastic tools for speeding up your site.

Luckily, installing Nginx from source isn’t too difficult. Even if you’ve never compiled any software from source, you can install Nginx. The remainder of this post will show you exactly how.

My Ideal Nginx Setup for Static Sites

Before we start installing, let’s go over the things we’ll be using to build a fast, lightweight server with Nginx.

Nginx.
SPDY — Nginx offers “experimental support for SPDY”, but it’s not enabled by default. We’re just going to enable it when we install Nginx. In my testing SPDY support has worked without a hitch, experimental or otherwise.
Google Page Speed — Part of Google’s effort to make the web faster, the Page Speed Nginx module “automatically applies web performance best practices to pages and associated assets”.
Headers More — This isn’t really necessary from a speed standpoint, but I often like to set custom headers and hide some headers (like which version of Nginx your server is running). Headers More makes that very easy.
Naxsi — Naxsi is a “Web Application Firewall module for Nginx”. It’s not really all that important for a server limited to static files, but it adds an extra layer of security should you decided to use Nginx as a proxy server down the road.

So we’re going to install Nginx with SPDY support and three third-party modules.

Okay, here’s the step-by-step process to installing Nginx on a Debian 7 (or Ubuntu) server. If you’re looking for a good, cheap VPS host I’ve been happy with Digital Ocean (that’s an affiliate link that will help support LongHandPixels; if you prefer, here’s a non-affiliate link: link)

The first step is to make sure you’re installing the latest release of Nginx. To do that check the Nginx download page for the latest version of Nginx (at the time of writing that’s 1.5.10).

Okay, SSH into your server and let’s get started.

While these instructions will work on just about any server, the one thing that will be different is how you install the various prerequisites needed to compile Nginx.

On a Debian/Ubuntu server you’d do this:

$ sudo apt-get -y install build-essential zlib1g-dev libpcre3 libpcre3-dev libbz2-dev libssl-dev tar unzip

If you’re using RHEL/Cent/Fedora you’ll want these packages:

$ sudo yum install gcc-c++ pcre-dev pcre-devel zlib-devel make

After you have the prerequisites installed it’s time to grab the latest version of Google’s Pagespeed module. Google’s Nginx PageSpeed installation instructions are pretty good, so I’ll reproduce them here with just one key change, I’m going to use the master archive rather than a numbered release.

First grab the latest version of PageSpeed:

$ wget https://github.com/pagespeed/ngx_pagespeed/archive/master.zip
$ unzip master.zip

Now, before we compile pagespeed we need to grab psol, which PageSpeed needs to function properly. So, let’s cd into the ngx_pagespeed-master folder and grab psol:

$ cd ngx_pagespeed-master
$ wget https://dl.google.com/dl/page-speed/psol/1.7.30.1.tar.gz
$ tar 1.7.30.1.tar.gz
$ cd ../

Alright, so the ngx_pagespeed module is all setup and ready to install. All we have to do at this point is tell Nginx where to find it.

Now let’s grab the Headers More and Naxsi modules as well. Again, check the Headers More and Naxsi pages to see what the latest stable version is and adjust the version numbers in the following accordingly.

$ wget https://github.com/agentzh/headers-more-nginx-module/archive/v0.24.tar.gz
$ tar -xvzf v0.24.tar.gz
$ wget https://github.com/nbs-system/naxsi/archive/0.53-2.tar.gz
$ tar -xvzf 0.53-2.tar.gz

Now we have all three third-party modules ready to go, we just need to grab a copy of Nginx itself:

$ wget http://nginx.org/download/nginx-1.5.10.tar.gz
$ tar -xvzf nginx-1.5.10.tar.gz

Then we cd into the Nginx folder and compile. So, first:

$ cd nginx-1.5.10

So now we’re inside the Nginx folder, let’s configure our installation. We’ll add in all our extras and turn off a few things we don’t need. Or at least they’re things I don’t need, obviously if you need the mail modules, then delete those lines. If you don’t need SSL, you might want to skip that as well. Here’s the config setting I use (Note: all paths are for Debian servers, you’ll have to adjust the various paths accordingly for RHEL/Cent/Fedora/ servers):

$ ./configure \
        --add-module=$HOME/naxsi-0.53-2/naxsi_src \
        --prefix=/usr/share/nginx \
        --sbin-path=/usr/sbin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --pid-path=/var/run/nginx.pid \
        --lock-path=/var/lock/nginx.lock \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/access.log \
        --user=www-data \
        --group=www-data \
        --without-mail_pop3_module \
        --without-mail_imap_module \
        --without-mail_smtp_module \
        --with-http_stub_status_module \
        --with-http_ssl_module \
        --with-http_spdy_module \
        --with-http_gzip_static_module \
        --add-module=$HOME/ngx_pagespeed-master \
        --add-module=$HOME/headers-more-nginx-module-0.24 \

There are a few things worth noting here. First off make sure that Naxsi is first. Here’s what the Naxsi wiki page has to say on that score: “Nginx will decide the order of modules according the order of the module’s directive in Nginx’s ./configure. So, no matter what (except if you really know what you are doing) put Naxsi first in your ./configure. If you don’t do so, you might run into various problems, from random/unpredictable behaviors to non-effective WAF.” The last thing you want is to think you have a web application firewall running when in fact you don’t, so stick with Naxsi first.

There are a couple other things you might want to add to this configuration. If you’re going to be serving large files, larger than your average 1.5MB HTML page, consider adding the line: --with-file-aio \, which is apparently faster than the stock sendfile option. See here for more details. There are quite a few other modules available. A full list of the default modules can be found on the Nginx site. Read through that and if there’s something else you need, just add it to the list.

Okay, we’ve told Nginx what to do, now let’s actually install it:

$ make
$ sudo make install

Once make install finishes doing its thing you’ll have Nginx all set up.

Congrats! You made it.

The next step is to add Nginx to the list of things your server starts up automatically whenever it reboots. Since we installed Nginx from scratch we need to tell the underlying system what we did.

Make it Autostart

Since we compiled from source rather than using Debian/Ubuntu’s package management tools, the underlying stystem isn’t aware of Nginx’s existence. That means it won’t automatically start it up when the system boots. In order to ensure that Nginx does start on boot we’ll have to manually add Nginx to our server’s list of startup services. That way, should we need to reboot, Nginx will automatically restart when the server does.

To do that I use the Debian init script listed in the Nginx InitScripts page:

If that works for you, just grab the raw version:

$ wget https://raw.github.com/MovLib/www/master/bin/init-nginx.sh
# move it to /etc/init.d/nginx
$ sudo mv init-nginx.sh /etc/init.d/nginx
# make it executable:
$ sudo chmod +x /etc/init.d/nginx
# then just:
$ sudo service nginx start #also restart, reload, stop etc

I suggest taking the last bit and turning it into an alias in your bashrc or zshrc file so that you can quickly restart/reload the server when you need it. Here’s what I use:

alias xrestart="sudo service nginx restart"
alias xreload="sudo service nginx reload"

Okay so we now have the initialization script all set up, now let’s make Nginx start up on reboot. In theory this should do it:

$ update-rc.d -f nginx defaults

But that didn’t work for me with my Digital Ocean Debian 7 x64 droplet (which complained that “insserv rejected the script header“). I didn’t really feel like troubleshooting that at the time; I was feeling lazy so I just decided to use chkconfig instead. To do that I just installed chkconfig and added Nginx:

$ sudo apt-get install chkconfig
$ sudo chkconfig --add nginx
$ sudo chkconfig nginx on

So there we have it, everything you need to get Nginx installed with SPDY, PageSpeed, Headers More and Naxsi. A blazing fast server for static files.

After that it’s just a matter of configuring Nginx, which is entirely dependent on how you’re using it. For static setups like this my configuration is pretty minimal.

Before we get to that though, there’s the first thing I do: edit /etc/nginx/nginx.conf down to something pretty simple. This is the root config so I keep it limited to just a http block that turns on a few things I want globally and an include statement that loads site-specific config files. Something a bit like this:

user  www-data;
events {
    worker_connections  1024;
}
http {
    include mime.types;
    include /etc/nginx/naxsi_core.rules;
    default_type  application/octet-stream;
    types_hash_bucket_size 64;
    server_names_hash_bucket_size 128;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;
    more_set_headers "Server: My Custom Server";
    keepalive_timeout  65;
    gzip  on;
    pagespeed on;
    pagespeed FileCachePath /var/ngx_pagespeed_cache;
    include /etc/nginx/sites-enabled/*.conf;
}

A few things to note. I’ve include the core rules file from the Naxsi source. To make sure that file exists, we need to copy it over to /etc/nginx/.

$ sudo cp naxsi-0.53-2/naxci_config/naxsi_core.rule /etc/nginx

Now let’s restart the server so it picks up these changes:

$ sudo service nginx restart

Or, if you took my suggestion of creating an alias, you can just type: xrestart and Nginx will restart itself.

With this configuration we have a good basic setup and any .conf files you add to the folder /etc/nginx/sites-enabled/ will be included automatically. So if you want to create a conf file for mydomain.com, you’d just create the file /etc/nginx/sites-enabled/mydomain.conf and put the configuration for that domain in that file.

I’m going to post a follow up on how I configure Nginx very soon. In the mean time here’s a pretty comprehensive guide to configuring Nginx in a variety of scenarios. And remember, if you want to some more helpful tips and tricks for web developers, sign up for the mailing list below.

If you’re more experienced with Nginx and I’m totally bass-akward about something in this guide, please let me know. ↩
In my experience anyway. Probably Apache can be tuned to get pretty close to Nginx’s performance with static files, but it’s going to take quite a bit of work. One is not necessarily better, but there are better tools for different jobs. ↩
That said, obviously a CDN service like Cloudfront will, in most cases, be much faster than Nginx or any other server. ↩

HTML5 Placeholder as a Label in Search Forms

Fri, 07 Feb 2014 14:38:00 EST

The HTML5 form input attribute placeholder is a tempting replacement for the good old <label> form element.

In fact the web is littered with sites that use placeholder instead of labels (or worse, JavaScript to make the value attribute act like label).

Just because a practice is widespread does not make it a best practice though. Remember “skip intro”? I rest my case. Similarly, you should most definitely not use placeholder as a substitute for form labels. It may be a pattern on today’s web, but it’s a shitty pattern.

Labels help users complete forms. There are mountains of data and eye tracking studies to back this up. If you want people to actually fill out your forms (as opposed, I guess, to your forms just looking “so clean, so elegant”) then you want to use labels. The best forms, from a usability standpoint, are forms with non-bold, left aligned labels above the field they label.

Again, using placeholder as a substitute for labels is a horrible UI pattern that you should (almost) never use.

Is that dogmatic enough for you? Oh wait, almost never. Yes, I think there is one specific case where maybe this pattern makes sense: search forms.

Search forms are so ubiquitous and so well understood at this point that it may be redundant to have a label that says “search”, a placeholder that also says “search” and a button that says “search” as well. I think just two of those would be fine.

We could skip the placeholder text, which should really be more of a hint anyway — e.g. “Jane Doe” rather than “Your Name” — but what if we want to dispense with the label to save a bit of screen real estate, which can be at a premium on smaller viewports?

The label should still be part of the actual HTML, whether your average sighted user actually sees it or not. We need it there for accessibility. But with search forms, well, maybe you can tuck that label away, out of site.

Progressive enhancement dictates that the labels should most definitely be there though. Let’s consider a simple search form example:

<form action="/search" method="get">
    <label id="search-label" for="search">Search:</label>
    <input type="text" name="search" id="query" value="" placeholder="Search LongHandPixels"> 
    <input class="btn" type="submit" value="Search">
</form>

Here we have our <label> tag and use the for attribute to bind it with the text input that is our search field. So far, so good for best practices.

Here’s what I think is the progressive enhancement route for search forms: use the HTML above and then use JavaScript and CSS to hide away the label when the it makes sense to do so. In other words, don’t just hide the label in CSS.

Hiding the label with something like label {visibility: hidden;} is a bad idea. That, and its evil cousin display: none; hide elements from screen readers and other assistive devices. Instead we’d want to do something like this:

.search-form-label-class {
    position: absolute; 
    left: -999em;
}

Check out Aaron Gustafson’s ALA article Now You See Me for more details on the various ways to hide things visually without hiding them from people who may need them the most.

So this code is better, our label is off-screen and the placeholder text combined with descriptive button text serve the same purpose and still make the function of the form clear. The main problem we have right now is we’ve hidden the label in every browser, even browsers that won’t display the placeholder attribute. That’s not so great.

In this case you might argue that the button still makes the form function relatively clear, but I think we can do better. Instead of adding a rule to our stylesheet, let’s use a bit of JavaScript to apply our CSS only if the browser understands the placeholder attribute. Here’s a bit of code to do that:

<script>
if (("placeholder" in document.createElement("input"))) {
    document.getElementById("search-label").style.position= 'absolute';
    document.getElementById("search-label").style.left= '-999em';
}
 </script>

This is just plain JavaScript, if your site already has jQuery or some other library running them by all means use it’s functions to select your elements and apply CSS. The point is the if statement, which tests to see if the current browser support the placeholder attribute. If it does them we hide the label off-screen, if it doesn’t then nothing happens. Either way the element remains accessible to screen readers.

If you’d like to see it in action, here’s a working demo: HTML5 placeholder as a label in search form

So is this a good idea? Honestly, I don’t know. It might be splitting hairs. I think it’s okay for search forms or other single field forms where there’s less chance users will be confused when the placeholder text disappears.

Pros:

Saves space (no label, which can be a big help on small viewports)
Still offers good accessibility

Cons:

Technically this is wrong. I’m essentially using JavaScript to make placeholder take the place of a label, which is not what placeholder is for.
Placeholders can be confusing. Some people won’t start typing a search term because they’re waiting for the field to clear. Others will think that the field is filled and the form can be submitted. See Chris Coyier’s CSS-Tricks site for some ideas on how you can make it apparent that the field is ready for input.
Not good for longer forms. Again, multi-field forms need labels. Placeholders disappear when you start typing. If you forget which field you’re in after you start typing, placeholders are no help. Despite the fact that the web is littered with forms that do this, please don’t. Use labels on longer forms.

I’m doing this with the search form on this site. I started to do the same with my new mailing list sign up form (which isn’t live yet), which is what got me writing this, thinking aloud as it were. My newsletter sign up form will have two fields, email and name (only email is required), and after thinking about this some more I deleted the JavaScript and left the labels.

If I shorten the form to just email, which I may, depending on some A/B testing I’m doing, then I may use this technique there too (and A/B test again). As of now though I don’t think it’s a good idea for that form for the reasons mentioned above.

I’m curious to hear from users, what do you think of this pattern? Is this okay? Unnecessary? Bad idea? Let me know what you think.

Work Smarter: The Plain Text Workflow

Sun, 02 Feb 2014 19:37:00 EST

If you’ve ever struggled building responsive websites, this post is for you. It’s part of a series on responsive design and smarter workflows, all pulled from my book, Responsive Web Design. If you find this excerpt useful, and want even more ideas on how responsive design can help you create amazing websites, sign up for the newsletter below and you’ll get a discount when the book is released.

If your current workflow looks anything like mine used to, you probably start most of your design work in a graphics editor like Photoshop. There’s nothing “wrong” with that per say, nor is Photoshop some tool for evil, but I’m here to tell you there is a better, more productive way to work.

Here’s the thing: if you’re designing websites in Photoshop you’re doing too much work.

If you’re building responsive websites and you’re not working directly with the code in a web browser you’re wasting time and energy using the wrong tool for the job. There’s nothing wrong with Photoshop, but it’s not the best tool for developing responsive websites.

Why?

Photoshop has a fixed canvas size; the web has an infinitely flexible canvas. Responsive design means embracing that flexible canvas and you can’t do that when you’re working in a graphics editor.

The web browser is the only tool I know of that offers the same fluid, flexible canvas of the web. If you want to simplify and optimize your responsive workflow, the place to work is in the browser.

Designing in the browser means working with the web rather than against it, and that’s the first step toward a simpler, faster responsive design workflow.

Faster, Easier Web Development? Sign Me Up!

For a long time I ignored the advice to design in the browser because often the people giving it stopped with the advice. Go design in the browser! It’s awesome! And, unicorns! Whereas I would just sit there thinking, Uuuuuuuh, okay, but what the heck does that mean? Design in the browser…? Grumble, well, I’ve got work to do and I know how to use Photoshop…

Designing directly in the web browser makes sense at a theoretical level, but what does it mean in practical terms? What does this workflow look like and where do you start?

That’s why I wrote this, to outline how I finally figured out I could save tremendous time and effort working directly in the browser rather than prototyping everything in Photoshop. I’m going to share my workflow in hopes it will prove useful to you.

Before we dive in, realize that this is just my workflow. It’s not THE workflow by any means. Whether you’re part of a small team, large team or working on your own, you have your idiosyncrasies and tics to consider. A good workflow will work with, not against you. I can’t tell you how you should work. I can, however, tell you how I work and hopefully that will give you some ideas you can test in your own workflow. Take what you need, skip what you don’t.

In the first part of this responsive design workflow series we looked at a super simple way to serve files on our local development machines. After all, you can’t design in the browser if you don’t have a server for your web browser to talk to. So I’ll assume you’ve completed that tutorial (or have your own web server setup already).

Everything Starts with the Content

The first thing to do with any tough question is to break it down into smaller questions. So instead of asking what does designing in the browser look like, let’s start with a more basic question: What do we need before we can display a webpage?

The simple answer is: the content.

Before we can do anything with HTML or CSS we need the contents of our site. Everything starts with content. No content, no HTML. No HTML, no CSS.

The foundation of any design has to be the content. I know what you’re thinking; you’re thinking I’ll just grab some Lorem Ipsum. Or, if you prefer some snarky for your dev work, Samuel L. Ipsum. But that’s not going to cut it.

Without the content we’re designing in the dark. I can’t remember where I first saw a graphic like this, but it’s what turned the light bulb on for me…. Simply put, there’s no point in designing a layout with this:

The content you think you’re going to get.

When what you’re actually need to display looks like this:

The content you actually got.

As Jeffery Zeldman writes, “design in the absence of content is not design, it’s decoration.” We’re not decorating websites, we’re designing them, which means we need actual content.

In terms of workflow, this means you need to get the content as soon as you can. No content, no work to flow. It means that when you’re meeting with clients you need to emphasize the importance of having the actual content, not placeholders, but actual content. Without the content you can’t make the client’s vision a reality. You need real content to build real websites.

If you’re doing a redesign of existing content, you’re all set, just dump the site using a tool like curl or wget¹ and then do a content inventory — list all the contents and make a special note of any patterns, repeated content and outlier content you find.

Once you have the content you can move on to sketching and wireframing — figuring out the structure of the pages and overall site. I tend to do this stage mostly on paper because I find that to be the fastest way to get my ideas recorded, but I’ve seen other developers who use iPads with styluses, mind mapping tools, even one who used spreadsheets to create wireframes (yeah, he was a little strange).

Once I have a good idea of the hierarchy and structure of the content on the site, I immediately jump into the browser and start working with live HTML. At this point I’m just stacking text and creating structure, there’s no CSS yet.

There are two necessary components in this workflow: the web server and the files.

Tool #1: The Web Server

For the full details on how you can start a web server in any folder on your computer, see the first part of this series. To quickly recap where we left off, recall that we set up our example project in ~/Sites/myproject/. We then open up our terminal application and type:

cd ~/Sites/myproject/ && serve

Assuming you set up the aliases outlined in the first post, this will start up a server in the myproject folder. Now point your browser to http://localhost/:8080 and you should see a directory listing of… nothing! That’s okay, the important thing is that we’ve got a server up and running.

Now we’re ready to turn our content into actual HTML files.

Tool #2: Plain Text

Up until now I’ve been using a phrase I don’t particularly like — “the content”. That makes it sound like it’s just a pile of stuff. But it’s not. It’s words, phrases, sentences, pitches, headlines, sub headlines, outlines, lists, tables, buttons, forms, charts, illustrations, images, videos. “The content” is generic, the contents of the site you’re building are not. This isn’t just semantics, it’s your first clue in how to get your workflow in line with the web itself.

Notice two that almost everything in that list is either text, an image or a video.

At its core this is what the web is made of — text and images. This is why starting your work in a graphics editor doesn’t make sense. The web is mostly text. Even fancy landing pages and ultra-slick web apps are ultimately about serving up text and images in the some way.

And within that core, for most sites, “the content” is text. So when we’re designing in the browser we’ll start where the web does, with text. Then we’ll add structure to that text. Then we can actually design pages optimized to display that structured text rather than just decorating some filler and hoping for the best.

The Power of Markdown

Starting with just the text makes it much easier to see the structure of your content and mark it up accordingly.

To my mind the best way to markup your documents at this stage is to use John Gruber’s Markdown. Markdown is a text-to-HTML conversion tool which allows you to markup text using an easy-to-read, easy-to-write format and then convert it to structurally valid HTML. While it won’t allow you to markup every thing you might need in the end, it’s perfect for generating quick prototypes like this. You can read through the Markdown documentation over on Daring Fireball.

Best of all the syntax of Markdown is extremely simple, you can pick it up in an afternoon and reach the level of mastery we need in a day or two.

To markup our content we’d just dive into our plain text files and add a bit of structure. Let’s say you had some text that looks like this:

Acme Widgets

We're Awesome Widget Makers

Crank your widgets faster with ACME Widgets

Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.

What can ACME Widgets do for you?

We can help you build better subwidgets
We can make you life widgetier
We can solve all your widget headaches

Let’s use Markdown to add some structure. The result might look something like this:

#We're Awesome Widget Makers

##Crank your widgets faster with ACME Widgets

Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.

###What can ACME Widgets do for you?

* We can help you build better subwidgets
* We can make your life widgetier
* We can solve all your widget headaches

You can refer to the Markdown docs for more details on the syntax, but the main thing to know is that # will be converted to <h1>, ## to <h2> and so on. The asterisks denote an unordered list. The sentences in the middle will automatically be wrapped in <p> tags. We’ve added structure to the text, but kept things readable.

Why bother? Why not go straight to HTML? Well, in this case the content is simple enough that sure, you might as well, but with much more complex, real-world content marking everything up in pure HTML is going to make it very difficult to read. Remember, this is the prototyping stage, things will be changing and you’ll likely need to edit, rearrange and change your content many times. The more readable it is, the easier it is to make those structural changes.

Tools for Converting to Plain Text

Unfortunately, it’s rare that a client gives you plain text files. Most clients deliver content in MS Word files or PDFs or something even stranger. I had one client who sent over all their content as a series of PowerPoint presentations.

The good news is that almost any files can be reduced to plain text. Regardless of how the client delivers the content, I convert it to plain text. For Word files I just open and save as plain text. That won’t preserve any formatting, but you can keep the original around just to make sure you get the hierarchy and structure right.

For PDFs I use a tool called pdftotext. OS X users can grab a handy installer from Carsten Blüm. There are also numerous free online PDF-to-text converters, as well as OCR software available. If the client hands you content in PowerPoint slides you can open it in PowerPoint, save it as a Rich Text document and then open the Rich Text document in TextEdit or similar and save as plain text.

The point is to get your content in plain text form.

Pandoc for Fame and Fortune

The next step is to convert our Markdown-formatted file into an HTML file we can view in the browser using the server we set up above. There’s a nearly unlimited number of ways we can convert from Markdown to actual HTML, but my favorite is Pandoc.

Installing Pandoc is simple, just head over to the Pandoc download page and grab the installer for your platform (for OS X grab the .dmg file, for Windows grab the .msi). Then double click the installer and follow the directions.

Once you have Pandoc installed you just need to run it on your markdown files. To do that fire up a terminal application. On OS X that would be Applications >> Utilities >> Terminal. On Windows you’ll need Cygwin.

I know, the command line is antiquated, mysterious and a bit frightening for many people.

I know that because it was that way for me too. But I kept noticing how much faster I could do things compared to visual apps. And I found that every time I used the terminal, it got a little less intimidating. I learned how to do one little thing that sped up my overall workflow. Then I learned another. And another. Today I use the terminal more than any other application. You don’t have to go that far, but don’t let it intimidate you. Just take it slow. Start with one thing that simplifies your life, like the web server trick.

With that one already under your belt you’re ready for Pandoc.

Open your terminal and navigate to your project folder. To stick with the previous tutorial in this series we’ll say our project files are in ~/Sites/myproject:

cd ~/Sites/myproject

Now that we’re in the right directory we just need to invoke Pandoc:

pandoc -s --smart -t html5 -o about.html about.txt

This line says, take the file about.txt, convert it from Markdown to HTML5 (that’s the -t html5 bit) and save the results in a new file named about.html. The -s flag at the beginning of the line tells Pandoc that we want this to be a standalone conversion, which means Pandoc will add <html>, <head>, <body> and a few other tags so that we have an actual valid HTML file rather than just a fragment of HTML. Pandoc even adds a link to the HTML5shiv for IE.

The --smart flag turns on one little extra feature that converts straight quotes to actual or curly quotes.

Point your web browser to http://localhost:8080/about.html and you should see the results. View source and you’ll notice that Pandoc has done a bunch of stuff:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta name="generator" content="pandoc">
    <title></title>
    <style type="text/css">code{white-space: pre;}</style>
    <!--[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
    <![endif]-->
</head>
<body>
    <h1 id="were-awesome-widget-makers">We're Awesome Widget Makers</h1>
    <h2 id="crank-your-widgets-faster-with-acme-widgets">Crank your widgets faster with ACME Widgets</h2>
    <p>Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.</p>
    <h3 id="what-can-acme-widgets-do-for-you">What can ACME Widgets do for you?</h3>
    <ul>
        <li>We can help you build better subwidgets</li>
        <li>We can make your life widgetier</li>
        <li>We can solve all your widget headaches</li>
    </ul>
</body>
</html>

Pandoc has converted all our Markdown formatting into actual HTML. Our hashes change to header tags and our list gets marked up as an unordered list. Don’t worry too much about the IDs and all the header elements. That can be changed or deleted when you move to working with templates in an actual content management system.

As you can see we have a nicely structured HTML file which can serve as the basis of our templates or undergo further editing to add things like a site-wide navigation menu, header, logo and the like.

Hmm. Maybe that list at the end should be an ordered list (probably not, but for example’s sake, go with me here). Well, that’s easy to change. Just open up the about.txt files and change the markdown to look like this:

#We're Awesome Widget Makers

##Crank your widgets faster with ACME Widgets

Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.

###What can ACME Widgets do for you?

1. We can help you build better subwidgets
2. We can make you life widgetier
3. We can solve all your widget headaches

Run the same Pandoc command (tip: if you hit the up arrow in your terminal app it will bring up the last used command. Assuming you’ve done nothing else in the mean time, that will be the Pandoc command we ran before).

Refresh your browser and you should see that the list of things ACME widgets can do for you is now an ordered list. Hmm, maybe that header should be an H2? Maybe the client just called, they’re sending over some updates for the page. None of that’s a problem any more, you just update your text file, run Pandoc and see the results. Simple.

Further

So far we’ve established a very basic, but fast workflow. We take our client provided content, convert it to text and with just two lines of code create HTML files and serve them locally for prototyping and structuring.

All this does is give you quick and dirty HTML you can use for prototyping. Why is that useful?

As Stephen Hay has said repeatedly (and written a book about, which you should read), starting with raw, unstyled HTML forces you to focus and prioritize. Hay suggests asking yourself, “what is the message that needs to be communicated if I was only able to provide them with unstyled HTML?” Start there, with the content — the most important content — and design everything around that.

We’ve got that basic unstyled HTML. What if you want to get a little bit fancier with Pandoc? Well, you certainly can. I do.

In the next installment in this series we’ll look at some advanced ways to use Pandoc including customizing the HTML template it uses, adding site-wide elements like navigation, headers and footers, as well as the part most designers all waiting for — adding an actual stylesheet.

So stay tuned. In the mean time, you can head over the Pandoc documentation if you’d like to get a head start.

If you want to learn some more handy tips and tricks for improving your responsive design workflows, I’m writing a book to teach you exactly that (and a whole lot more). Sign up for the mailing list below to hear more about the book and get a discount when it’s released.

If you prefer a graphical download check out Sitesucker for OS X or HTTrack for Windows ↩

The Easiest Way to Get Started 'Designing in the Browser'

Fri, 08 Nov 2013 16:02:00 EST

If you’ve ever struggled to “design in the web browser” this post is for you.

You’ve probably heard that phrase before, “designing in the browser”, especially when it comes to building responsive websites. Some people even go so far as to say you shouldn’t use Photoshop at all, but should build everything right in the browser.

I think you should choose whatever tool works the best for you, but since I switched to developing directly in the browser a few years ago I’ve been able to greatly simplify my workflow. Skipping intermediary tools like Photoshop means I’m able to accomplish more in less time, which in turn means I can say yes to more projects.

Sounds awesome right? But where do you start?

How to Simplify “Designing in the Browser”

Start with the content. Get your content from the client, make your sketches, your wireframes, whatever other preliminary things are already part of your workflow. Then, when that’s done, instead of opening Photoshop, Illustrator or other layout apps, you convert that content to HTML and start structuring it to match your wireframes.

But how? I start up a web browser (I use Firefox), point it to my local mockup files (just HTML files in my project folder) and start editing. That’s it; that’s my workflow: edit, refresh; edit, refresh. It’s simple and it makes the feedback loop of design and development immediate and simple.

And to do that I didn’t spend hours setting up some complex development environment, nor did I have to buy some expensive GUI server software package. In fact, I use just one line of code to pull this off.

Here’s how you can simplify your responsive design workflow, and start “designing in the browser” with what I call “the Python web server trick”. I’ve been doing this for so long I often assume everyone knows about this, but I keep meeting people who don’t. So… if you don’t, here’s a dead simple way to serve files locally with just one line of code.

The Best Web Server is the One That’s Already Installed

The key to designing in the browser is to have a quick and easy way to serve up files locally. You don’t need anything fancy at this stage, just a basic web server.

The easiest way I have found to set up this workflow is to use a very simple command line tool that creates a web server wherever I want it, whenever I want it.

I know, I know, the command line is antiquated, mysterious and a bit frightening for many people. I know that because it was that way for me too. But I kept noticing how much faster I could do things compared to visual apps. And I found that every time I used the terminal, it got a little less intimidating. I learned how to do one little thing that sped up my overall workflow. Then I learned another. And another. Today I use the terminal more than any other application. You don’t have to go that far, but don’t let it intimidate you. Just take it slow. Start with one thing that simplifies your life, like this web server trick.

If you’ve ever tried to set up a local development environment with Apache, PHP and the like you probably know what a headache that can be. Well, it turns out, if all you want is a simple web server, there’s a much easier way.

Here’s how to turn any local folder on your Mac or Linux machine into a web server (Windows users can do the very same thing, though first you’ll need to install Python. Follow these instructions to get Python installed and then come back and follow along).

Before we start our web server we need a folder to hold all our files. This folder will be the “root” of our web server. I divide my time between OS X and Linux, which both offer a “Sites” folder in your home folder. I use this folder to store all my projects. If you prefer to store things elsewhere just adjust all the path names in the code that follow. Open the Sites folder and create a new folder inside it named myproject. Then create a new file named mydemo.html. Open that file in your favorite editor and just type “Hello World”.

That gives us something to test with. The next step is to open up your terminal application. In OS X that means you head to the Applications folder, open the Utilities folder and then double-click the Terminal application (Windows users head to the Start Menu, click Run and then type cmd; if you’re on Linux I’ll assume you know how to open a terminal window). In the new Terminal window type/paste this line:

cd ~/Sites/myproject

The command cd just means “change directory”. So we’ve changed from our home user folder to the myproject directory. Okay, you’re now inside the folder we created just a minute ago. Now type this line:

python -m SimpleHTTPServer 8080

Now open your favorite web browser and head to the URL: localhost:8080/. You should now see a directory listing with a link to your mydemo.html file. Click that and you should see “Hello World”. Go back to your text editor and change the mydemo.html file to read “Hello World, it’s nice to meet you”. Jump back to the browser and reload the page. You should now see the message “Hello World, it’s nice to meet you”

Congratulations! You created a web server. You now have a simple and fast way to serve up HTML files locally. You can edit, refresh and mock up live HTML files right in the browser.

All we’re doing here is taking advantage of the fact that the Python programming language ships with a built-in web server. Since Python is built into OS X and Linux, it’s always there, ready to serve up files (as noted above, if you’re on Windows you’ll need to install Python. I also suggest installing Cygwin, it will make everything you do on the command line easier).

Improving the Script

So we have a very basic way to serve files locally. There are various ways to make this more sophisticated, but this basic method will work when you’re first getting started.

If you don’t mind another quick trip to the Terminal you can even automate the process some more. To make it even simpler we can add an alias to what’s known as a “profile”, the configuration file that loads every time we start up a new terminal window. Most operating systems these days ship with the Bash shell. Assuming that’s what you have (OS X uses Bash by default, as do most Linux distros), open a new terminal window and type this:

nano ~/.bash_profile

Now paste this line into the window:

alias serve='cd ~/Sites/myproject && python -m SimpleHTTPServer 8080'

Hit control-x, type a “y” and hit return to save the file. Now quit your terminal app and restart it.

Now to turn on the server all we need to do is open a new terminal window and type “serve”. Note that if your folder is in a different location, or if you move the folder you’ll need to adjust your alias accordingly.

If you’ve got a home network running and you’d like to be able to see your website on all your devices (handy for testing on phones, tablets and whatnot), you can alter this code slightly so other local devices can connect to your server. It’s a little more complicated, but can still be a one-liner.

For example, if your machine’s local network address is 192.168.1.5, you could run this command:

python -c "import BaseHTTPServer as bhs, SimpleHTTPServer as shs; bhs.HTTPServer(('192.168.1.5', 8080), shs.SimpleHTTPRequestHandler).serve_forever()"

Now, instead of localhost, open the URL 192.168.1.5:8080 in your web browser and you’ll see the same page, but now you can point your phone to that URL and it will load there as well. Ditto your tablet, Kindle and any other devices connected to your local network.

Obviously that’s tough to remember so let’s create an alias. To do that we’ll just add another alias to the .bash_profile file we edited earlier. To open that up again just enter:

nano ~/.bash_profile

Now paste this line into the window:

alias serve_all="python -c 'import BaseHTTPServer as bhs, SimpleHTTPServer as shs; bhs.HTTPServer(('\''192.168.1.5'\'', 8080), shs.SimpleHTTPRequestHandler).serve_forever()'"

Now you can cd into any directory, type serve_all and run a web server that you can use to testing your sites on any device.

That’s all there is to it. A live web server whenever you want it, wherever you want it.

That’s how I “design in the browser”.

The next step is to take that nice content the client gave us and put it into our mockup files so we have something more useful than “Hello World” in our web browser. I do this using plain text files, Markdown and Pandoc, which I cover in more detail in this follow-up post: Work Smarter: The Plain Text Workflow.

I hope this simple Python server trick proves helpful, and, if you have any questions, drop them in the comments below.

Responsive Images & `srcset`

Mon, 30 Sep 2013 20:08:00 EST

There are, in my experience, three pain points in any responsive design — tabular data, advertising and images. The latter is the most interesting problem to me since it’s not something you can design or engineer your way around. True, there are ways you can coerce today’s browsers into doing roughly what you want — serve large images to large screens and small ones to small screens — but these are really hacks, sometimes very clever hacks, but still hacks.

Nathan Ford has put together a nice Responsive Images Mega-List in an attempt to catalog all the ways you can handle images in a responsive site today.

That’s a great list of resources for handling images today, but what I’ve been obsessing over lately is the future, when we won’t need all these workarounds.

Just like we hacked video into the web using Flash and eventually got the <video> tag, we’re hacking responsive images into the web and eventually the web is going to give us a native solution. In fact, there’s one just around the browser update bend.

How `srcset` Simplifies Responsive Images

The exciting thing is that there are not just one, but two responsive image solutions already in the works. The W3C is working on a couple of new tools aimed at making responsive images less complex. The first new feature that’s likely to make it to a browser near you is the new srcset attribute for the <img> tag.

[Update 02 Feb 2014: Everything below is still true, but it looks like srcset will be part of the proposed <picture> element rather than part of <img> (or it may be part of both, that’s still up in the air a bit). In other words, the WebKit nightly support may well be the only time srcset works on an <img> tag. The syntax on the <picture> element is the same, though it’s used within a <source> tag.]

The proposed srcset attribute has a controversial history, which I wrote about several times on Webmonkey. I don’t think any of that matters at this point though. It’s true that srcset doesn’t address everything about responsive images, but it looks to me like it covers the 80 percent use case and, more importantly, there is already some browser support (and more on the way).

Here’s how srcset works:

<img alt="Image Desc"
   src="image.jpg"
   srcset="image-HD.jpg 2x, image-phone.jpg 320w, image-phone-HD.jpg 320w 2x">

As you can see, the srcset attribute takes a comma-separated list of values. Within each item in the list you have three variables. First there’s the URL to the image, then there’s a maximum viewport dimension (optional) and then an optional pixel density (for targeting higher resolution screens). So the srcset value image-HD.jpg 2x tells the browser, roughly, if you’re on a display with high-res screen then grab this high-res image. Pretty simple. You can of course make it much more complex by adding several other images to the list, for example, to target various screen widths.

There are two major drawbacks to srcset. First, you can only specify screen width (or height) in pixels. The reason has to with how browsers pre-fetch content, which happens long before there’s enough info to calculate the value of a percentage or em width/height. See this thread on the W3C mailing list for details. The bottom line is, flexible units for srcset is a no-go.

The other major drawback is that you can only specify the equivalent of max-width when defining the viewport dimensions. There is no min-width or orientation support like you’d use in CSS @media queries. That means you may not be able to line your srcset breakpoints up with your CSS breakpoints.

There’s some other stuff in the spec worth noting as well. For instance, “if the viewport dimensions or pixel density changes, the user agent can replace the image data with a new image on the fly.” That means (I think) that, while there’s no equivalent to CSS 3 @media’s orientation query, you could get the same effect because the viewport dimensions change on rotation, triggering larger images to load (though to make that work you’d end up targeting specific device widths, which is not future-friendly). It’s hard to imagine a scenario in which the pixel density would change, but hey, why not I guess?

There is one very cool part of the spec though, it puts the ultimate decision about which images are served in the hands of the user.

No browser supports it, but the spec says that the higher res images specified in srcset are just candidates. Here’s the relevant bit:

Optionally, return the URL of an entry in candidates chosen by the user agent, and that entry’s associated pixel density, and then abort these steps. The user agent may apply any algorithm or heuristic in its selection of an entry for the purposes of this step.

So in theory the browser gets the final say. This means the browser can check the available network and make a decision about whether or not to actually obey srcset. For instance it might reject the high-res images on 3G, but accept them over wifi. Even better, mobile browsers could add a user preference so users can say (as they can today with native apps), “I only want high-res images over wifi”. Or all the time or whatever. The user is in control.

I think that’s probably the best way to handle what’s possibly a user-developer conflict. For example, I want my images to look good on your retina iPad, but you might want to save your (possibly) expensive bandwidth for other things. I think the user should trump the developer in that scenario. With srcset the browser can give the user the power to make that decision.

Testing `srcset` Today

This is all largely academic right now. Only one browser supports srcset and even that’s just the nightly builds of Apple’s WebKit.

If you want to see it in action, go grab the latest WebKit nightly. Here’s a live demo:

This first test is for retina displays, which looks like this:

<img alt="demo of srcset in action"
  src="/media/images/demos/srcsetdemo-fallback.jpg" 
  srcset="/media/images/demos/srcsetdemo-2x.jpg 2x"  />

This test is for mobile screens with a maximum viewport of 420px, here’s the code:

<img alt="demo of srcset in action" 
    src="/media/images/demos/srcsetdemo-fallback.jpg" 
    srcset="/media/images/demos/srcsetdemo-widthquery.jpg 420w" />

The last test is for mobile high res screens and uses this code:

<img alt="demo of srcset in action"
    src="/media/images/demos/srcsetdemo-fallback.jpg" 
    srcset="/media/images/demos/srcsetdemo-mobile2x.jpg 420w x2" />

This final test is designed to check WebKit’s current implementation, which does not yet support specifying a width. It’s the same query as above, but with a much wider max-width which should trigger it to load in desktop WebKit Nightly.

<img alt="demo of srcset in action"
    src="/media/images/demos/srcsetdemo-fallback.jpg" 
    srcset="/media/images/demos/srcsetdemo-superwidequery.jpg 9000w"  />

As of September 30, 2013, using the latest WebKit Nightly (v8536.30.1, 538+) only the first test works. WebKit only supports the pixel density queries, not the max viewport width query.

Which Web Browsers Support `srcset`?

Eventually caniuse.org will probably add srcset (I think they require at least one shipping version of the feature before they’ll track it), but for now I threw together a table for keeping track of which web browsers support srcset.

Here’s the list as of November 15, 2013:

Browser	`srcset` support
WebKit Nightly	yes
Safari 6	no
Firefox 25	no
Chrome 29	no
Opera 16	no
IE 10	no
Mobile Safari 7	no
Opera Mini 7	no
Opera Mobile 14	no
Android Default 4.2	no
Chrome for Android	no
Firefox for Android	no

Yes, it’s a slightly ridiculous table, but with any luck Chrome will be joining the list of srcset supporters in the very near future. That means that Opera will be there as well. My contacts at Mozilla tell me that Firefox is also working on support. So things are looking pretty good for the future. That doesn’t help today though, so if you need something now, remember to check out Nathan Ford’s Responsive Images Mega-List for a complete collection of responsive image solutions that work today.

Writing in the Open

Wed, 25 Sep 2013 14:14:00 EST

Whew! Crazy weekend. I wasn’t really prepared for how the web would react to learning that Webmonkey is no more. My inbox blew up. Clearly Webmonkey will be missed. Thanks to everyone who sent me their thoughts on Webmonkey shutting down and all the stories about learning HTML (DHTML natch), CSS or JavaScript from the site. Also, glad to hear that there are apparently so many Webmonkey beanies out there. Anyway, if I’m a little slow responding to you, I apologize, but rest assured I have read everyone’s email and I will get back to you all in the next few days

In the mean time, you should go read Brad Frost’s recent post on Designing in the Open.

Frost and his wife, Melissa, are redesigning the Greater Pittsburgh Community Food Banks website and have decided to do everything in the open so the rest of us can see the process. There’s a very cool looking timeline and a post about their process so far. In that post Melissa quotes a comment Josh Long wrote some time ago on Chris Coyier’s Working in Public post (itself a good example) about why you would want to risk the potential embarrassment or ridicule or whatever else you’re afraid of to work publicly:

It makes you think clearly and directly.

It forces you to know what the hell you’re talking about.

It shows people how much you put into your work.

It’s a great way to document your work.

It’s a great way to give back and teach others.

To that I would add a couple more: it teaches you what you know (and don’t), and it’s fun, because really, if this isn’t fun you shouldn’t do it.

The main reason we don’t show our processes more or work in public is fear. Fear that, as Melissa Frost says, you’ll embarrass yourself or that you’ll be seen as a fraud or . Fear is self-created though. Fear is our reaction to an imaginary negative event we’ve projected into the future. It’s something that might happen, but hasn’t. Fear can be helpful. For example, you’re afraid you’ll forget about an important meeting and that fear prompts you to write it down on your calendar. But more often than not fear is not helpful. More often than not fear - that imaginary projection into the future - ends up inhibiting us in the present. It stops you from sharing the stuff you’ve made for instance. I put off launching this site for months, at least partly out of fear.

So fuck fear. I don’t have a cool looking timeline like the Frosts’, nor do I have a super cool working new/old design split for this site like Sparkbox’s open redesign site. But, in lieu of anything else, I do have a screenshot of my responsive web design book in progress:

b’

\n \n

Please pardon the terrible titles/subtitles. Those will be improved before this thing goes on sale, I promise.

\n\n’

Does that count as working in the open? Probably not. But that’s the best I can do at the moment. One of the early issues of McSweeneys had a line drawing of a bird with one wing, below it was the caption “trying, trying, trying”. That’s how I feel.

If there’s interest I could write more about what it’s like to write a book (which I could title, how I tricked myself into writing 40,000 words in three weeks). At some point I’d like to take working in the open even further and put the “source” of the book in a public Git repository to make it easy for other people to fix typos, contribute resource links or, well - who knows what else people might end up doing?

I think that’s probably the best reason to do anything “in the open” - it opens more doors for other people. Yeah some of them will be jerks and trolls. But in my experience most of them are not.

And opening the door to others opens the door to serendipity. And serendipity often leads to magic.

When you put things out in the world the world takes them, plays with them - sometimes nicely, sometimes not - and unexpected things start to happen. In my experience these things tend to be good. Random @replies morph into friends, ideas spark others’ imaginations. I find there ends up being a lot of synchronicity - ideas colliding in interesting ways, what Robert Anton Wilson called “Coincidance“.

I’ve never tried designing in the open, but I’d like to do more writing in the open. If you’ve got any good ideas on how to do that, please let me know.

Okay, back to work.

Whatever Happened to Webmonkey.com?

Fri, 20 Sep 2013 21:12:00 EST

People on Twitter have been asking what’s up with Webmonkey.com. Originally I wanted to get this up on Webmonkey, but I got locked out of the CMS before I managed to do that, so I’m putting it here.

Earlier this year Wired decided to stop producing new content for Webmonkey.

For those keeping track at home, this is the fourth, and I suspect final, time Webmonkey has been shut down (previously it was shut down in 1999, 2004 and 2006).

I’ve been writing for Webmonkey.com since 2000, full time since 2006 (when it came back from the dead for a third run). And for the last two years I have been the sole writer, editor and producer of the site.

Like so many of you, I learned how to build websites from Webmonkey. But it was more than just great tutorials and how tos. Part of what made Webmonkey great was that it was opinionated and rough around the edges. Webmonkey was not the product of professional writers, it was written and created by the web nerds building Wired’s websites. It was written by people like us, for people like us.

I’ll miss Webmonkey not just because it was my job for many years, but because at this point it feels like a family dog to me, it’s always been there and suddenly it’s not. Sniff. I’ll miss you Webmonkey.

Quite a few people have asked me why it was shut down, but unfortunately I don’t have many details to share. I’ve always been a remote employee, not in San Francisco at all in fact, and consequently somewhat out of the loop. What I can say is that Webmonkey’s return to Wired in 2006 was the doing of long-time Wired editor Evan Hansen (now at Medium). Evan was a tireless champion of Webmonkey and saved it from the Conde Nast ax several times. He was also one of the few at Wired who “got” Webmonkey. When Evan left Wired earlier this year I knew Webmonkey’s days were numbered.

I don’t begrudge Wired for shutting Webmonkey down. While I have certain nostalgia for its heyday, even I know it’s been a long time since Webmonkey was leading the way in web design. I had neither the staff nor the funding to make Webmonkey anything like its early 2000s self. In that sense I’m glad it was shut down rather than simply fading further into obscurity.

I am very happy that Wired has left the site in place. As far as I know Webmonkey (and its ever-popular cheat sheets, which still get a truly astounding amount of traffic) will remain available on the web. That said, note to the Archive Team, it wouldn’t hurt to create a backup. Sadly, many of the very earliest writings have already been lost in the various CMS transitions over the years and even much of what’s there now has incorrect bylines. Still, at least most of it’s there. For now.

As for me, I’ve decided to go back to what I enjoyed most about the early days of Webmonkey: teaching people how to make cool stuff for the web.

To that end I’m currently working on a book about responsive design, which I’m hoping to make available by the end of October. If you’re interested drop your email in the box below and I’ll let you know when it’s out (alternately you can follow @LongHandPixels on Twitter).

If you have any questions or want more details use the comments box below.

In closing, I’d like to thank some people at Wired — thank you to my editors over the years, especially Michael Calore, Evan Hansen and Leander Kahney who all made me a much better writer. Also thanks to Louise for always making sure I got paid. And finally, to everyone who read Webmonkey and contributed over the years, whether with articles or even just a comment, thank you.

Cheers and, yes, thanks for all the bananas.