Kiss My Classname

SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.

I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.

I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.

Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.

The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.

Ten Years Ago on the Web

2006 DOESN’T seem forever ago until I remember that we were tracking IE7 bugsworrying about the RSS feed validator, and viewing Drupal as an accessibility-and-web-standards-positive platform, at the time. Pundits were claiming bad design was good for the web (just as some still do). Joe Clark was critiquing WCAG 2. “An Inconvenient Truth” was playing in theaters, and many folks were surprised to learn that climate change was a thing.

I was writing the second edition of Designing With Web Standards. My daughter, who is about to turn twelve, was about to turn two. My dad suffered a heart attack. (Relax! Ten years later, he is still around and healthy.) A List Apart had just added a job board. “The revolution will be salaried,” we trumpeted.

Preparing for An Event Apart Atlanta, An Event Apart NYC, and An Event Apart Chicago (sponsored by Jewelboxing! RIP) consumed much of my time and energy. Attendees told us these were good shows, and they were, but you would not recognize them as AEA events today—they were much more homespun. “Hey, kids, let’s put on a show!” we used to joke. “My mom will sew the costumes and my dad will build the sets.” (It’s a quotation from a 1940s Andy Hardy movie, not a reflection of our personal views about gender roles.)

Jim Coudal, Jason Fried and I had just launched The Deck, an experiment in unobtrusive, discreet web advertising. Over the next ten years, the ad industry pointedly ignored our experiment, in favor of user tracking, popups, and other anti-patterns. Not entirely coincidentally, my studio had just redesigned the website of Advertising Age, the leading journal of the advertising profession.

Other sites we designed that year included and Gnu Foods. We also worked on Ma.gnolia, a social bookmarking tool with well-thought-out features like Saved Copies (so you never lost a web page, even if it moved or went offline), Bookmark Ratings, Bookmark Privacy, and Groups. We designed the product for our client and developed many of its features. Rest in peace.

I was reading Adam Greenfield’s Everyware: The Dawning Age of Ubiquitous Computing, a delightfully written text that anticipated and suggested design rules and thinking for our present Internet of Things. It’s a fine book, and one I helped Adam bring to a good publisher. (Clearly, I was itching to break into publishing myself, which I would do with two partners a year or two afterwards.)

In short, it was a year like any other on this wonderful web of ours—full of sound and fury, true, but also rife with innovation and delight.

As part of An Event Apart’s A Decade Apart celebration—commemorating our first ten years as a design and development conference—we asked people we know and love what they were doing professionally ten years ago, in 2006. If you missed parts onetwothree, or four, have a look back.



The Year in Design

  • Mobile is today’s first screen. So design responsively, focusing on content and structure first.
  • Websites and apps alike should remove distractions and let people interact as directly as possible with content.
  • 90 percent of design is typography. And the other 90 percent is whitespace.
  • Boost usability and pleasure with progressive disclosure: menus and functions that appear only when needed.
  • One illustration or original photo beats 100 stock images.
  • Design your system to serve your content, not the other way around.
  • Remove each detail from your design until it breaks.
  • Style is the servant of brand and content. Style without purpose is noise.
  • Nobody waits. Speed is to today’s design what ornament was to yesterday’s.
  • Don’t design to prove you’re clever. Design to make the user think she is.

Also published in Medium

Translated into German (also here) by Mark Sargent

Translated into French by Jean-Baptiste Sachsé

Translated into Turkish by omerbalyali.

Translated into Spanish by Tam Lopez Breit.

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

Give me file hierarchies, or give me chaos.

IN “HOW DROPBOX Remains Relevant,” Khoi Vinh explains why Dropbox owes much of its success to subtly faceted, user-focused design:

Even in an age when the biggest operating systems in the world actively eschew file hierarchies, Dropbox is thriving—its service matters deeply to countless users. Why? In part it’s because the company works hard at making file hierarchies useful, that they focus on the outcomes of file management and not just on the files and folders.

Absolutely. Dropbox sweats the user experience details as commendably as it masters the considerable engineering challenges required to reliably sync files everywhere a user may need them.

But there’s another reason Dropbox succeeds. And it isn’t despite its emphasis on old-fashioned file hierarchies. It’s because of that emphasis.

⇛ ALTHOUGH Khoi may well be right that “smart passive management of design assets and working files seems inevitable,” I, for one, do not look forward to the day I no longer have direct access to my files and the ability to control where and how they are stored. To my way of thinking, passive management of file assets is okay for screwing around with iPads, where we’re mainly watching TV on Netflix or obsessive-compulsively checking the popularity of our Instagram uploads. But for real work, and even for passionate hobby work (like managing family photos), give me files and folders any day.

Stay with photos a moment. Consider snapshots. For my money, apps like Photos (and, formerly, iPhoto) that “save” me from the “inconvenience” of knowing where my images are do me no favors. Thanks, but no thanks. Let me save photos where I want to save them, not where the system thinks I should save them—typically on a laptop’s rapidly filling solid state hard drive with minimal storage capacity.

Dropbox, with its emphasis on good old-fashioned hierarchies, is superb at automatically saving one original of each photo I take, whether shot with a phone or a fancy camera. No loops, no duplicates, no confusion. In contrast, Photo’s cloud sync options, designed to spare the user the trouble of thinking, always trip me up. Like when, after syncing my phone to my home desktop computer, I tell Photos to delete the photos I’ve just sync’d from my phone. Photos obeys my command, and then instantly restores the photos to my phone from the “cloud.”

Why would a system expect a user who has deleted files to want those files restored a moment later? In what universe of scenarios can that possibly be what the user expects? [Your system may work differently from mine. Your deletes may stick. If so, good on you. You may have checked a different box in a hidden drawer of a preferences dialog, possibly in the app preferences you can set in the app itself, or possibly in the app preferences you set in the phone’s Settings app, or possibly online—say, in iCloud, or possibly in the iCloud settings in the phone’s Settings app. This is simplicity?]

Because my phone and iCloud restore photos as soon as they’re deleted, my Camera Roll is an unwieldly monster—despite my applying common sense, logic, years of design and computer using experience, and hours of conversation with a rapidly dwindling circle of friends—not to mention the hours I’ve spent scouring the web for hints. The whole situation reminds me of an article I saw on the cover of PC World years ago: “Plug ‘n Play: How To Make It Work.” (Hint: If you have to learn how to make it work, it ain’t plug ‘n play. And that’s kind of how I feel about the current state of passive file management.)

⇛ SYSTEMS designed to relieve you of thinking too often end up forcing you to think, and think, and think, without ever solving the problems their supposed simplicity has created for you. How much easier would photo maintenance on my phone be if Photos, like Dropbox, used file hierarchies? I could solve the problem myself in a second, with the click of a checkbox, if only Apple weren’t committed to chasing a future where nobody needs to know anything about how their computer works—and, as a result, some of us have no clue what to do when the computer doesn’t work quite right.

⇛ I UNDERSTAND that these are difficult problems to solve, and that confusion and frustration are the price consumers pay for innovation that may benefit them in the long run, once all the kinks are out. I’m not anti-innovation or anti-Apple.

But I’m a web person. I like files. I like editing a CSS file without necessarily having to edit an HTML file. I like fixing a problem by replacing a corrupted file with a clean one. Maybe I’m set in my ways, but I don’t consider it a hardship to open a folder or replace a file. I wouldn’t be quite as happy with a web where I didn’t “need” to “bother” writing CSS.

In the same way, I like deciding where files go—saving an image for Project A in a Project A folder, a text document for Project B in a Project B folder (and all of it in Dropbox). I’m glad Adobe Lightroom maintains a picture of my photo folder hierarchy in a sidebar of its interface, enabling me to see where my files live, and instantly choose a group of photos by date (instead of, say, scrolling through thousands of files visually). When it’s time to get dressed in the morning, I don’t throw myself into a giant room full of clothes. I pull socks from my sock drawer and shirts from my shirt drawer. I’ve been doing this since I was five years old. It’s not a challenge.

Khoi ends his excellent Dropbox piece thusly:

Maybe we’re all just set in our ways, but people seem at least resigned, and more likely just plain comfortable with managing their files. It may not be what future workflows are built around, but for working designers, the future is hypothetical, and Dropbox works today.

To which I say Amen. And add the hope that, so long as my career lasts, I can keep using a workflow I find easy and comprehensible.

Don’t make me think.” Absolutely. But, equally, don’t treat me like an idiot. Folders über alles.

Also published in Medium