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

Who’s Afraid of the Big Bad Medium?

IN 2003, long before he was a creative director at Twitter, Douglas Bowman wrote articles about design, posted case studies about his design projects, and shared his photography on his personal/business site,

A year previously, Doug had attained instant fame in standardista circles by recoding using CSS for layout. That sounds nonsensical nowadays, but in 2002, folks like me were still struggling to persuade our fellow web designers to use CSS, and not HTML tables, for layout. Leading web designers had begun seeing the light, and there had been a sudden profusion of blogs and personal sites that used CSS for layout, and whose markup strove to be semantic and to validate. But nobody had as yet applied web standards to a large commercial site—giving rise to the charge, among Luddite web designers, that standards-based design was “okay for blogs” but had no business on the “real” web.

Then Doug recoded with CSS, Mike Davidson did the same for, and all the old reactionary talking points were suddenly as dead as Generalissimo Franco—and the race was on to build a standards-compliant, open web across all content and application sectors.

IN THE PROCESS of helping to lead this sea change, Douglas Bowman became famous, and anybody who was anybody in web design began passionately reading his blog. And yet.

And yet, when Doug had a really big idea to share with our community, he published it on A List Apart, the magazine “for people who make websites.”

Did he do so because blogging was dead? Because the open web was in trouble? Of course not. He did it because publishing on A List Apart in 2003 allowed Doug to share his innovative design technique with the widest possible audience of his peers.

PUBLISHING in multiple venues is not new. Charles Dickens, the literary colossus of Victorian England, did it. (He also pioneered serial cross-cutting, the serial narrative, and the incorporation of audience feedback into his narrative—techniques that anticipated the suspense film, serial television narratives like Mad Men, and the modification of TV content in response to viewer feedback over the internet. But those are other, possibly more interesting, stories.)

Nobody said the open web was dead when Doug Bowman published “Sliding Doors of CSS” on A List Apart.

Nobody said the blog was dead when RSS readers made it easier to check the latest content from your favorite self-publishing authors without bothering to type their personal sites’ URLs into your browser’s address bar.

Forward thinkers at The New York Times did not complain when Mike Davidson’s Newsvine began republishing New York Times content; the paper brokered the deal. They were afraid to add comments to their articles on their own turf, and saw Newsvine as a perfect place to test how live reader feedback could fit into a New York Times world.

When Cameron Koczon noticed and named the new way we interact with online content (“a future in which content is no longer entrenched in websites, but floats in orbit around users”), smart writers, publishers, and content producers rejoiced at the idea of their words reaching more people more ways. Sure, it meant rethinking monetization; but content monetization on the web was mostly a broken race to the bottom, anyway, so who mourned the hastening demise of the “web user manually visits your site’s front page daily in hopes of finding new content” model? Not many of us.

By the time Cameron wrote “Orbital Content” in April of 2011, almost all visits to A List Apart and were triggered by tweets and other third-party posts. Folks were bookmarking Google and Twitter, not And that was just fine. If you wrote good content and structured it correctly, people would find it. Instead of navigating a front-page menu hierarchy that was obsolete before you finished installing the templates, folks in search of exactly your content would go directly to that content. And it was good.

So just why are we afraid of Medium? Aside from not soliciting or editing most of its content, and not paying most of its authors, how does it differ from all previous web publications, from Slate to The Verge? Why does publishing content on Medium (in addition to your personal site and other publications) herald, not just the final-final-final death of blogging (“Death of Blogging III: This Time It’s Personal”), but, even more alarmingly, the death of the open web?

You may think I exaggerate, but I’ve heard more than one respected colleague opine that publishing in Medium invalidates everything we independent content producers care about and represent; that it destroys all our good works with but one stroke of the Enter button.

I’ve even had that thought myself.

But isn’t the arrival of a new-model web publication like Medium proof that the web is alive and healthy, and spawning new forms of creativity and success?

And when the publisher of a personal site writes for Medium, is she really giving up on her own site? Couldn’t she be simply hoping to reach new readers?

(If she succeeds, some of those new readers might even visit her site, occasionally.)

Thanks to Bastian Allgeier for inspiring this post.

This piece was also published on Medium.

This article has been translated into Chinese.

Big Web Show № 127: Those Who Can Teach with Jared Spool

Jared Spool of Center Centre and User Interface Engineering

IN EPISODE № 127 of The Big Web Show, Jared Spool of User Interface Engineering and I discuss the goals and workings of Center Centre, a new school Jared cofounded with Dr Leslie Jensen Inman to create the next generation of industry-ready UX designers. Topics include “teaching students to learn,” what schools can and can’t do, working with partner companies, “Project Insanity,” and designing a program to make students industry-ready.


Center Centre
User Interface Engineering
UX Mobile Immersion
Unicorn Institute
Brain Sparks (UX writing by Jared and others)
All You Can Learn

Achieving Empathy for Institutions with Anil Dash

Anil Dash

IN BIG WEB SHOW № 115 on Mule Radio, I talk with Anil Dash, a hugely influential entrepreneur, blogger, and web geek living in NYC.

Things we discuss include:

How government, media, and tech shape the world, and how we can influence them in turn. Our first meeting at SXSW in 2002. How selling CMS systems teaches you the dysfunction at media companies and organizations. Working for the music industry at the dawn of Napster. RFP-EZ. The early days of blogging.

Designing websites for the government—the procurement problem. If we’re pouring all this time into social media, what do we want to get out of it? How big institutions work and how to have an impact on them. Living in “Joe’s Apartment.”

Why, until recently, federal agencies that wanted a blog couldn’t use WordPress or Tumblr and how the State Dept got on Tumblr. Achieving empathy for institutions. Being more thoughtful about what I share and who I amplify on social media. The launch of Thinkup, and a special offer exclusively for Big Web Show listeners.

Enjoy Big Web Show № 115.

Sponsored by An Event Apart, the design conference for people who make websites. Save $100 off any 2- or 3-day AEA event with discount code AEABWS.

Big Web Show № 98: Designer Debbie Millman

Debbie Millman

I CHAT with internet radio pioneer, design author, and brand maven Debbie Millman about broadcasting, writing, teaching, publishing, learning to be happy in your own skin, and the importance of early failure to long-term success and happiness. Enjoy Debbie Millman on The Big Web Show.

(Want more Debbie? Check Observer Media–Debbie’s legendary audio interviews with the likes of Jessica Walsh, Milton Glaser, Massimo Vignelli, Maria Popova, Stefan Sagmeister, Dave Eggers, Jen Bekman, Gary Hustwit, Tina Roth Eisenberg, Erik Spierkermann, Jessica Hische, and many more.)

The Lords of Vendorbation


noun : Unusable web-based intranet software foisted on large populations of users who have no say in the matter. For example, the “dynamic” website for your kid’s school, on which you can never find anything remotely useful—like her classroom or the names and email addresses of her teachers. Merely setting up an account can be a Borgesian ordeal minus the aesthetics.

Tried updating a driver’s license, registering a name change after a marriage, or accomplishing pretty much any task on a local, state, or federal website? Congratulations! You’ve been vendorbated. In ad sales? In publishing? Travel agent? Work in retail? Y’all get vendorbated a hundred times a day. Corporate America runs, not very well, on a diet of dysfunctional intranets sold by the lords of vendorbation.

Terrible food kills a restaurant. Terrible music ends a band’s career. But unspeakably terrible software begets imperial monopolies.

Wholesale contractual vendor lock-in between vendors of artless (but artfully initially priced) web software and the technologically unknowing who are their prey (for instance, your local school board) creates a mafia of mediocrity. Good designers and developers cannot penetrate this de-meritocracy. While they sweat to squeeze through needle’s eye after needle’s eye of baffling paperwork and absurd requirements, the vendorbators, who excel at precisely that paperwork and those requirements, breeze on in and lock ‘er down.

Vendorbation takes no heed of a user’s mental model; indeed, the very concept of a user’s mental model (or user’s needs) never enters the minds of those who create vendorbatory software. I say “create” rather than “design,” because design has less than nothing to do with how this genre of software gets slapped together (“developed”) and bloated over time (“updated”).

Vendorbatory product “design” decisions stem purely from contingencies and conveniences in the code framework, which itself is almost always an undocumented archipelago of spaghetti, spit, and duct tape started by one team and continued by others, with no guiding principle other than to “get it done” by an arbitrary deadline, such as the start of a new school year or the business cycle’s next quarter.

Masturbation, or so I have read, can be fun. Not so, vendorbation. It is a nightmare for everyone—from the beleaguered underpaid lumpen developers who toil in high-pressure silos; to the hapless bureaucrats who deserve partners but get predators instead; from the end users (parents, in our example) who can never do what they came to do or find what they want, and who most often feel stupid and blame themselves; to the constituents those users wish to serve—in our example, the children. Will no one think of the children?

Cha-ching! Like a zombie-driven un-merry-go-round spinning faster and faster as the innocents strapped to its hideous horses shriek silently, the vendorbation cycle rolls on and on, season after bloody season, dollar after undeserved dollar, error after error after error after error in saecula saeculorum.

Think it’s bad now? Wait till the lords of vendorbation start making their monstrosities “mobile.”

Doff of the neologist’s toque to Eric A. Meyer, whose cornpensation helped crystalize what to do with the bad feelings.

For Your Listening Pleasure

THE BIG WEB SHOW is back, baby! In spite of hurricanes, blackouts, and the vagaries of international travel, my 5by5 audio podcast about “everything web that matters” has returned to weekly broadcasting. Here are the latest episodes for your edification and listening pleasure:

Episode 76: Jen Robbins

Creator of four classic web design books (in 13 editions) Jennifer Robbins and I chat about her upcoming Artifact Conference for multi-device design; why sites are now systems, not pages; how style guides can function as a system design description tool; getting digital UX design into its natural habitat (hint: not a comp) sooner than later; what’s new in web design and the 4th Edition of her O’Reilly classic Learning Web Design; and loads more.

Jennifer Robbins has two decades of web design experience, having designed the first commercial website, O’Reilly’s Global Network Navigator (GNN), in 1993. She’s the author of O’Reilly’s Web Design in a Nutshell, and has taught web design at the Massachusetts College of Art in Boston and Johnson and Wales University in Providence, RI.

Episode 75: Evan Williams

Evan Williams, co-founder of Blogger, Twitter, and Medium, discusses what it’s like to be an internet entrepreneur, from the origin of product ideas to the art of the pivot. Ev is a notoriously private guy; it is wonderful to hear him open up and share his hard-won web wisdom in this episode.

Evan Williams is an American entrepreneur who has co-founded several internet companies, including Pyra Labs (creators of Blogger) and Twitter, where he was previously CEO. His new thing is Medium. Ev was born and raised on a farm in central Nebraska. He lives in San Francisco with his wife and two sons. He likes long walks, tofu, and bourbon. Ev has blogged for over a decade at; you can follow him on Twitter at @ev.

Episode 74: Chris Coyier

In Episode No. 74 of The Big Web Show, I interview Chris Coyier of CSS-Tricks, CodePen, and ShopTalk about the path from employee to media maven, upcoming secret features for CodePen, coping with Retina images, finding sponsors, the success of his Kickstarter campaign, tee shirts for manly men, Twitter dramas about baseline grids, and more.

Chris Coyier (@chriscoyier) founded and writes at CSS-Tricks, co-hosts a podcast at ShopTalk, and co-founded and is a designer at CodePen, a sort of Dribble for coders.

Episode 73: Sara Wachter-Boettcher

I chat with content strategist and author of Content Everywhere Sara Wachter-Boettcher (@sara_ann_marie) about how practitioners can organize and structure content to maximize its value, longevity, and future-friendliness.

Sara Wachter-Boettcher is a content strategist and writer based in Lancaster, Pennsylvania, where she drinks strong coffee and sometimes blogs. She is editor in chief at A List Apart magazine, and her book, Content Everywhere, is due out from Rosenfeld Media in the very near future. You can find Sara on Twitter trying not to say all the snarky things she thinks.

Episode 72: Derek Powazek

For the return of The Big Web Show, I speak with web pioneer Derek Powazek (@fraying), Founder and CEO of Cute-Fight, the online game for real-life pets and the people who love them.

Derek Powazek has worked the web since 1995 at pioneering sites like HotWired, Blogger, and Technorati. He is the author of Design for Community: The Art of Connecting Real People in Virtual Places (New Riders, 2001) and the cofounder of JPG, the photography magazine that’s made by its community. He has also been Chief of Design for HP’s MagCloud, advisor to a handful of startup companies, and creator of Fray, the quarterly book of true stories and original art. Derek is now Founder and CEO of Cute-Fight, the online game for real-life pets and the people who love them. Derek lives in San Francisco with his wife, two nutty Chihuahuas, and a house full of plants named Fred.

My mind and welcome to it

IN MY DREAM I was designing sublime new publishing and social platforms, incandescent with features no one had ever thought of, but everybody wanted.

One of my platforms generated pages that were like a strangely compelling cross between sophisticated magazine layouts and De Stijl paintings. Only, unlike De Stijl, with its kindergarten primary colors, my platform synthesized subtle color patterns that reminded you of sky and water. Anyone – a plumber, a fishmonger – could use the tool to immediately create pages that made love to your eyes. In the hands of a designer, the output was even richer. Nothing on the web had ever touched it.

Then the dream changed, and I was no longer the creator. I was a sap who’d been off sniffing my own armpits while the internet grew up without me. A woman I know was using the platform to create magazines about herself. These weren’t just web magazines, they were paper. And they weren’t just paper. In the middle of one of her magazines was a beautiful carpet sample. The platform had designed the carpet and woven it into the binding of the printed magazine. I marveled at her output and wished I had invented the platform that allowed her to do these things. Not only was I no longer the creator, I seemed to be the last sap on earth to even hear about all these dazzling new platforms.

Then I was wandering down an endless boardwalk, ocean on my right, a parade of dreary seaside apartment buildings on my left. Each building had its own fabulous content magazine. (“Here’s what’s happening at 2171 Oceanfront Walk.”) The magazines appeared on invisible kiosks which revealed themselves as you passed in front of each building. The content, created by landlords and realtors, was so indifferent as to be unreadable. But this did not matter a bit, because the pages so dazzled in their unholy beauty that you could not look away. Every fool in the world had a meaningless publication which nobody read, but which everyone oohed and ahed at as they passed. And I — I had nothing to do with any of it. I was merely a spectator, a chump on a tiresome promenade.

For Tim and Max. You are the future.

Build Books With CSS3; Design a Responsive Résumé

“WE ARE ALL PUBLISHERS,” claims Issue No. 353 of A List Apart for people who make websites. Design books with CSS3; craft a responsive web résumé.

Building Books with CSS3


While historically, it’s been difficult at best to create print-quality PDF books from markup alone, CSS3 now brings us the Paged Media Module, which targets print book formatting. “Paged” media exists as finite pages, like books and magazines, rather than as long scrolling stretches of text, like most websites. With a single CSS stylesheet, publishers can take XHTML source content and turn it into a laid-out, print-ready PDF. You can take your XHTML source, bypass desktop page layout software like Adobe InDesign, and package it as an ePub file. It’s a lightweight and adaptable workflow, which gets you beautiful books faster. Nellie McKesson, eBook Operations Manager at O’Reilly Media, explains how to build books with CSS3.

A Case for Responsive Résumés


Grizzled job hunting veterans know too well that a sharp résumé and near-flawless interview may still leave you short of your dream job. Competition is fierce and never wanes. Finding new ways to distinguish yourself in today’s unforgiving economy is vital to a designer/developer’s survival. Happily, web standards whiz and mobile web developer Andrew Hoffman has come up with a dandy differentiator that is just perfect for A List Apart readers. Learn how to author a clean résumé in HTML5/CSS3 that scales well to different viewport sizes, is easy to update and maintain, and will never grow obsolete.

Illustration by Kevin Cornell for A List Apart.