Responsive times two: essential new books from Ethan Marcotte & Karen McGrane

Responsive Design times two! New books from the geniuses, Ethan Marcotte and Karen McGrane.

IT WAS the early 2000s. The smoke from 9/11 was still poisoning my New York.

Karen McGrane was a brilliant young consultant who had built the IA practice at Razorfish while still in her early 20s, and was collaborating with my (now ex-)wife on some large, exciting projects for The New York Public Library. Ethan Marcotte was a Dreadlocks-hat-sporting kid I’d met in Cambridge through Dan Cederholm, with whom he sometimes collaborated on tricky, standards-based site designs. The first edition of my Designing With Web Standards was in the can. I figured that, like my previous book, it would sell about 10,000 copies and then vanish along with all the other forgotten web design books.

Nothing happened as I expected it to. The only thing I got right besides web standards was the desire to some day work with Karen, Ethan, and Dan—three dreams that, in different ways, eventually all came true. But nothing, not even the incredible experience of working with these luminaries, could have prepared me for the effect Ethan and Karen and Dan would have on our industry. Even less could I have guessed back then the announcement it’s my pleasure to make today:

Ethan Marcotte’s Responsive Design: Patterns and Principles and Karen McGrane’s Going Responsive are now available in our A Book Apart store.

It was thrilling to bring you Ethan and Karen’s first industry-changing A Book Apart books. Being allowed to bring you a second set of absolutely essential works on responsive design from these two great minds is a gift no publisher deserves, and for which I am truly grateful.

Building on the concepts in his groundbreaking Responsive Web Design, Ethan now guides you through developing and using design patterns so you can let your responsive layout reach more devices (and people) than ever before.

Karen McGrane effortlessly defined the principles of Content Strategy for Mobile. She’s helped dozens of teams effectively navigate responsive projects, from making the case to successful launch. Now, she pulls it all together to help you go responsive—wherever you are in the process.

Ebooks are available immediately and paperbacks ship next week. Buy Responsive Design: Patterns and Principles and Going Responsive together and save 15%! (Learn more.)

“Adaptive UI encourages us to be strategic.”

Adaptive UI across devices.

[M]ost things simply respond automatically, like content width responding to text size changes; some things need to be modified like the Profile header, which would take up half the screen on a large device if we didn’t modify the layout; only a few things need to be rethought, like Direct Messages, where the list of conversations can sit side-by-side with the conversations when you have a wide enough screen.

Mike Davidson on Building a more unified Twitter for iOS

You’re welcome: cutting the mustard then and now.

EVERY TIME I hear a young web developer cite the BBC’s forward-thinking practice of “cutting the mustard,” by which they mean testing a receiving web device for certain capabilities before serving content, I remember when my team and I at The Web Standards Project invented that very idea. It’s a million web years ago, by which I mean fourteenish human years ago, so nobody remembers but me and some other long toothed grayhairs, plus a few readers of the first edition of Designing With Web Standards. But I like you, so I will tell you the story.

Back then in those dark times, it was common practice for web developers to create four or more versions of the same website—one for each browser then in wide use. It was also a typical (and complementary) practice to send server-side queries to figure out which browser was about to access a site’s content, and then send the person using that browser to the site version that was configured for her browser’s particular quirks, proprietary tags, and standards compliance failings.

The practice was called “browser detection.” Nobody but some accessibility advocates had ever questioned it—and the go-go dot-com era had no time or care for those folks.

But we at The Web Standards Project turned everything on its head. We said browsers should support the same standards instead of competing to invent new tags and scripting languages. We said designers, developers, and content folks should create one site that was accessible to everyone. In a world like that, you wouldn’t need browser detection, because every browser and device that could read HTML would be able to feast on the meat of your site. (And you’d have more meat to share, because you’d spend your time creating content instead of crafting multiple versions of the same site.)

To hasten that world’s arrival, in 2001 we launched a browser upgrade campaign. Those who participated (example participant here) employed our code and content to send their users the message that relatively standards-compliant browsers were available for every platform, and inviting them to try one. Because if more people used relatively standards-compliant browsers, then we could urge more designers and developers to create their sites with standards (instead of quirks). And as more designers and developers did that, they’d bump against still-unsolved standards compliance conundrums, enabling us to persuade browser makers to improve their standards compliance in those specific areas. Bit by bit, stone by stone, this edifice we could, and would, erect.

The code core of the 2001 browser upgrade campaign was the first instance of capability detection in place of browser detection. Here’s how it worked. After creating a valid web page, you’d insert this script in the head of your document or somewhere in your global JavaScript file:

if (!document.getElementById) {
window.location =

We even provided details for various flavors of markup. In HTML 4 or XHTML 1 Transitional documents, it looked like this:

<script type="text/javascript" language="javascript">
<!-- //
if (!document.getElementById) {
window.location =
// -->

In STRICT documents, you’d either use a global .js file, or insert this:

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
// -->

You could also just as easily send visitors to an upgrade page on your own site:

if (!document.getElementById) {
window.location =

Non-WaSP members (at the time) J. David Eisenberg, Tantek Çelik, and Jim Heid contributed technical advice and moral support to the effort. WaSP sysadmin Steven Champeon, the inventor of progressive enhancement, made it all work—under protest, bless him. (Steve correctly believed that all web content should always be available to all people and devices; therefore, in principle, he disliked the upgrade campaign, even though its double purpose was to hasten the arrival of truly standards-compliant browsers and to change front-end design and development from a disrespected world of hacks to a sustainable and professional craft. ((See what I did there? I’m still respectfully arguing with Steve in my head.)))

Discovering rudimentary DOM awareness or its absence in this fashion was the first time web developers had tested for capabilities instead of chasing the dragon in a perpetual and futile attempt to test for every possible browser flavor and version number. It was the grandparent, if you will, of today’s “cutting the mustard.” And it is analogous as well to the sensible responsive design practice of setting breakpoints for the content, instead of trying to set appropriate breakpoints for every possible device out there (including all the ones that haven’t been invented yet).

Which reminds us that the whole point of web standards was and is forward compatibility—to create content that will work not only in yesterday’s and today’s browsers and devices, but in all the wonderful devices that have yet to be invented, and for all the people of the world. You’re welcome.

—CHICAGO, Westin Chicago River Hotel, 1 September 2015

Hat tip: John Morrison

On Web Performance

Lara Hogan

GET READY for Lara Hogan, author of Designing For Performance, as she shares pretty much about everything you’ll need to know to design optimally performant front-end web experiences. It’s one of twelve essential sessions that make An Event Apart Austin 2015 the Southwest’s don’t-miss web design and development event of 2015.

Publishing v. Performance—or, The Soul of the Web

MY SOUL is in twain. Two principles on which clued-in web folk heartily agree are coming more and more often into conflict—a conflict most recently thrust into relief by discussions around the brilliant Vox Media team, publishers of The Verge.

The two principles are:

  1. Building performant websites is not only a key differentiator that separates successful sites from those which don’t get read; it’s also an ethical obligation, whose fulfillment falls mainly on developers, but can only happen with the buy-in of the whole team, from marketing to editorial, from advertising to design.
  2. Publishing and journalism are pillars of civilized society, and the opportunity to distribute news and information via the internet (and to let anyone who is willing to do the work become a publisher) has long been a foundational benefit of the web. As the sad, painful, slow-motion decline of traditional publishing and journalism is being offset by the rise of new, primarily web-based publications and news organizations, the need to sustain these new publications and organizations—to “pay for the content,” in popular parlance—is chiefly being borne by advertising…which, however, pays less and less and demands more and more as customers increasingly find ways to route around it.

The conflict between these two principles is best summarized, as is often the case, by the wonderfully succinct Jeremy Keith (author, HTML5 For Web Designers). In his 27 July post, “On The Verge,” Jeremy takes us through prior articles beginning with Nilay Patel’s Verge piece, “The Mobile Web Sucks,” in which Nilay blames browsers and a nonexistent realm he calls “the mobile web” for the slow performance of websites built with bloated frameworks and laden with fat, invasive ad platforms—like The Verge itself.

The Verge’s Web Sucks,” by Les Orchard, quickly countered Nilay’s piece, as Jeremy chronicles (“Les Orchard says what we’re all thinking”). Jeremy then points to a half-humorous letter of surrender posted by Vox Media’s developers, who announce their new Vox Media Performance Team in a piece facetiously declaring performance bankruptcy.

A survey of follow-up barbs and exchanges on Twitter concludes Jeremy’s piece (which you must read; do not settle for this sloppy summary). After describing everything that has so far been said, Mr Keith weighs in with his own opinion, and it’s what you might expect from a highly thoughtful, open-source-contributing, standards-flag-flying, creative developer:

I’m hearing an awful lot of false dichotomies here: either you can have a performant website or you have a business model based on advertising. …

Tracking and advertising scripts are today’s equivalent of pop-up windows. …

For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.

Me, I’m torn. As a 20-year-exponent of lean web development (yes, I know how pretentious that sounds), I absolutely believe that the web is for everybody, regardless of ability or device. The web’s strength lies precisely in its unique position as the world’s first universal platform. Tim Berners-Lee didn’t invent hypertext, and his (and his creation’s) genius doesn’t lie in the deployment of tags; it subsists in the principle that, developed rightly, content on the web is as accessible to the Nigerian farmer with a feature phone as it is to a wealthy American sporting this year’s device. I absolutely believe this. I’ve fought for it for too many years, alongside too many of you, to think otherwise.

And yet, as a 20-year publisher of independent content (and an advertising professional before that), I am equally certain that content requires funding as much as it demands research, motivation, talent, and nurturing. Somebody has to pay our editors, writers, journalists, designers, developers, and all the other specialtists whose passion and tears go into every chunk of worthwhile web content. Many of you reading this will feel I’m copping out here, so let me explain:

It may indeed be a false dichotomy that “either you can have a performant website or you have a business model based on advertising” but it is also a truth that advertisers demand more and more for their dollar. They want to know what page you read, how long you looked at it, where on the web you went next, and a thousand other invasive things that make thoughtful people everywhere uncomfortable—but are the price we currently pay to access the earth’s largest library.

I don’t like this, and I don’t do it in the magazine I publish, but A List Apart, as a direct consequence, will always lack certain resources to expand its offerings as quickly and richly as we’d like, or to pay staff and contributors at anything approaching the level that Vox Media, by accepting a different tradeoff, has achieved. (Let me also acknowledge ALA’s wonderful sponsors and our longtime partnership with The Deck ad network, lest I seem to speak from an ivory tower. Folks who’ve never had to pay for content cannot lay claim to moral authority on this issue; untested virtue is not, and so on.)

To be clear, Vox Media could not exist if its owners had made the decisions A List Apart made in terms of advertising—and Vox Media’s decisions about advertising are far better, in terms of consumer advocacy and privacy, than those made by most web publishing groups. Also to be clear, I don’t regret A List Apart’s decisions about advertising—they are right for us and our community.

I know and have worked alongside some of the designers, developers, and editors at Vox Media; you’d be proud to work with any of them. I know they are painfully aware of the toll advertising takes on their site’s performance; I know they are also doing some of the best editorial and publishing work currently being performed on the web—which is what happens when great teams from different disciplines get together to push boundaries and create something of value. This super team couldn’t do their super work without salaries, desks, and computers; acquiring those things meant coming to some compromise with the state of web advertising today. (And of course it was the owners, and not the employees, who made the precise compromise to which Vox Media currently adheres.)

Put a gun to my head, and I will take the same position as Jeremy Keith. I’ll even do it without a gun to my head, as my decisions as a publisher probably already make clear. And yet, two equally compelling urgencies in my core being—love of web content, and love of the web’s potential—make me hope that web and editorial teams can work with advertisers going forward, so that one day soon we can have amazing content, brilliantly presented, without the invasive bloat. In the words of another great web developer I know, “Hope is a dangerous currency—but it’s all I’ve got.”

Also published in Medium.

The Nation, America’s oldest weekly news magazine, launches responsive, large-type redesign.

ON ITS 150th anniversary, The Nation (“a magazine of ideas and values”) relaunches its website, created in partnership with Blue State Digital and Diaspark. As one would expect of an editorially focused web entity in 2015, the new site is responsive, and uses big type and clean layouts designed for readability. It also incorporates social media innovations first seen in Medium, such as the ability to tweet or email any brief passage of text you select.

Executive Editor Richard Kim’s mini-article introducing the new site explains how the editorial process has changed—and how it has stayed the same—since the launch of the magazine’s first site in 1997:

Back then, writing for the magazine was a comparatively monastic experience. You’d work for weeks on an article, defend its arguments against vigorous but loving critiques from the editors, and gratefully accept changes from fact-checkers and copy editors. Finally, the issue would ship to the printer. And then: the vast silence. If you were lucky, a few weeks later, someone might approach you at a party and say how much they liked (or hated) your piece. Some letters from impassioned subscribers would eventually come in via the Postal Service, but encounters with actual readers were rare and cherished events.

We continue to publish the print magazine under these rigorous standards, and it will remain an essential part of our identity, offering readers a considered and curated take on matters of critical interest. The digital revolution, however, has allowed us to connect to vastly more people, and to get to know them better. Today, The Nation publishes about 70 articles a week online, which go out to more than 420,000 Twitter followers, almost 290,000 Facebook fans, and 200,000 e-mail subscribers. And believe me, we always hear back from you….

There’s also a multi-tiered approach to reading and commenting:

For the next few months, there’s no paywall: All of our articles will be free to everyone—our gift to you in The Nation’s 150th-anniversary year. Later, we’ll introduce a metered system that continues to put The Nation in front of new readers, but also asks our regular visitors to contribute to the cost of independent journalism. Finally, only subscribers will be able to leave comments—and they’ll be asked to identify themselves with a first and last name. We realize this will be controversial to some, but keeping the comments free of trolls and bots has taken an increasing amount of effort. We think it’s only fair that commenters stand by what they write, and give something to the community in return.

A List Apart № 423: container queries, responsive content

A List Apart 423

WHETHER the topic is responsive CSS or content that responds to the right user at the right time, Issue № 423 of A List Apart is all about finding the path forward:

Container Queries: Once More Unto the Breach

by Mat Marquis

Mat MarquisMedia queries have been the go-to tool in building responsive sites, allowing us to resize and recombine modules to suit multiple contexts, layouts, and viewports. But relying on fixed viewport sizes can quickly twist stylesheets into Gordian knots. We still need a future-friendly way to manage responsive CSS. Mat Marquis explores the problem and the progress toward the solution—and issues a rallying call.

Create a Content Compass

by Meghan Casey

Meghan CaseyContent projects need a sense of direction: something to help you and your team provide the right content to the right people at the right time. Enter the content compass—centered on your strategy and supported by your messaging—to keep your content efforts on track. In this excerpt from Chapter 11 of The Content Strategy Toolkit, Meghan Casey explains her methodology for developing a core strategy statement and messaging framework.

Responsive Web Design’s Debut (with video)


IT WAS FIVE years ago today, Ethan Marcotte taught the web to play…nicely with all kinds of devices in all kinds of contexts. And he did it live on stage at An Event Apart Seattle 2010. Watch the video that changed the web forever.

Evolving Responsive Web Design

In What We Mean When We Say “responsive” and Defining Responsiveness, Lyza Danger Gardner and Jason Grigsby cut to the heart of a disagreement I had three years ago with Ethan Marcotte, the creator of Responsive Web Design and author of Responsive Web Design, a book I published in 2011.

Ethan told the world that Responsive Web Design required, and was defined by, fluid layouts, flexible images, and media queries. All three elements had to be present. If they weren’t using all three, you might be doing something interesting, but you were most definitely not doing Responsive Web Design.

Ethan invented all of this. Without him, we would likely be arguing whether it was time to consider 1280 pixels the new default fixed width for all desktop websites, and sending anything that wasn’t a desktop browser to a function- and content-limited “mobile site” whose URL began with the letter m. Ethan is a brilliant, multi-talented innovator; I am but the shadow of a hack. And yet, before he began creating his book, midway through the writing, and even a year after I published it, I continued to urge Ethan to rethink #RWD as “a bigger idea”—a concept rather than a single set of techniques.

I’m no genius. What I meant by “bigger idea” was limited to the notion that we’d one day be able to create responsive layouts with different techniques—so let’s not restrict the concept to a particular execution. I wasn’t thinking about other meanings of responsive, wasn’t considering problems of responsive content, and so on. I’m not that forward-thinking and it was three freaking years ago, come on.

I lost my gentle argument with Ethan, so the industry is having it now. And that’s just as it should be. Everything worked out for the best. Here’s why:

If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside, as previous insights into the fluid nature of the web have done. The simplicity, elegance, and completeness of the package—here’s why, and here’s how—sold the idea to thousands of designers and developers, whose work and advocacy in turn sold it to hundreds of thousands more. This wouldn’t have happened if Ethan had promoted a more amorphous notion. Our world wouldn’t have changed overnight if developers had had too much to think about. Cutting to the heart of things and keeping it simple was as powerful a creative act on Ethan’s part as the “discovery” of #RWD itself.

We’ve only become ready to think about things like “responsible” responsive design, adaptive content, and a standard approach to responsive images now that we have built our share of first-generation responsive sites, and encountered the problems that led to the additional pondering. Baby steps. Brilliant baby steps.

Some commenters want to use initial-capped Responsive Web Design to mean responsive design as Ethan first defined it, and lowercase responsive design to mean an amorphous matrix of exciting and evolving design thinking. Lyza says soon we’ll stop saying Responsive altogether, a conclusion Andy Clarke reached three years ago.

Me, I like that Ethan stuck to his guns, and that the classical definition will always be out there, regardless of how web design evolves thanks to it. Kind of like there’s HTML 5, a defined and scoped W3C specification, and HTML living standard, an evolving activity. Our industry needs roots and wings, and, lucky us, we’ve got ’em both.

Big Web Show № 112: Responsive Images Get Real with Mat Marquis

Mat Marquis

THE GOAL of a “responsive images” solution is to deliver images optimized for the end user’s context, rather than serving the largest potentially necessary image to everyone. Unfortunately, this hasn’t been quite so simple in practice as it is in theory.

In Big Web Show № 112, I sit down with Mat Marquis, chair of the W3C Responsive Images Community Group, to discuss guidelines for responsive images in multi-device design. We talk about the history, theory, and multi-leveled challenge of responsive images, the path to standardization, and what browsers will do next.


URLs in this Episode