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

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.

No Good Can Come of Bad Code: Ask Dr Web in A List Apart

Remember: the future will come whether you design for it or not. If your company charges $300,000 for a website that won’t work on next week’s most popular device, your company won’t be able to stay competitive in this business. It might not even be able to stay in the business, period. After all, clients who pay for sites that break too soon will look elsewhere next time—leaving your company perpetually hunting for new clients in a downward spiral of narrowing margins and diminishing expectations.

Your company’s survival is tied to the ability of the products it makes to work in situations you haven’t imagined, and on devices that don’t yet exist. This has alwaysbeen the challenge of web design. It’s one A List Apart has taken seriously since we began publishing, and our archives are filled with advice and ideas you can boil down and present to your bosses.

Source: No Good Can Come of Bad Code


I’VE BEEN BUSY this month:

And March is only half over.

The Long Web – An Event Apart Video

Jeremy Keith at An Event Apart

IN THIS 60-minute video caught live at An Event Apart Austin, Jeremy Keith bets on HTML for the long haul:

The pace of change in our industry is relentless. New frameworks, processes, and technologies are popping up daily. If you’re feeling overwhelmed, you are not alone. Let’s take a step back and look at the over-arching trajectory of web design. Instead of focusing all our attention on the real-time web, let’s see which design principles and development approaches have stood the test of the time. Those who cannot remember the past are condemned to repeat it, but those who can learn from the past will create a future-friendly web.

Enjoy The Long Web by Jeremy Keith – An Event Apart Video.

Follow An Event Apart on Twitter, Google+, or Facebook. And for the latest web design news plus special offers, discounts, and more, subscribe to the AEA mailing list.

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 79: Eric Meyer

Eric Meyer

IN EPISODE No. 79 of The Big Web Show (“everything web that matters”), I interview CSS guru, Microformats co-founder, O’Reilly and New Riders author, and An Event Apart co-founder Eric A. Meyer (@meyerweb) about upcoming CSS modules including grid layout, flexbox, and regions; his career trajectory from college graduate webmaster to world-renowned author, consultant, and lecturer; founding and running a virtual community (CSS-Discuss); becoming an O’Reilly writer; the early days of the Mosaic Browser and The Web Standards Project’s CSS Samurai; “The Web Behind” variation of The Web Ahead podcast, and more.

Listen to the episode.

About Eric

Eric A. Meyer has been working with the web since late 1993 and is an internationally recognized expert on the subjects of HTML and CSS. He is the principal consultant for Complex Spiral Consulting and lives in Cleveland, Ohio, which is a much nicer city than you’ve been led to believe. Author of “Eric Meyer on CSS” (New Riders), “Cascading Style Sheets: The Definitive Guide” (O’Reilly & Associates), “CSS2.0 Programmer’s Reference” (Osborne/McGraw-Hill), and the CSS Browser Compatibility Charts, Eric co-founded and co-directs An Event Apart, the design conference “for people who make websites,” and speaks at a variety of conferences on the subject of standards, CSS use, and web design.


Photo: Chris Jennings

Big Web Show 77: @sazzy

IN EPISODE No. 77 of The Big Web Show, I interview returning guest Sarah Parmenter about designing an app for the homeless; the challenges of multi-device design; teaching HTML and CSS to young people; designing a complex reader app; the ideal number of employees for a small design studio; Brooklyn vs. small-town UK; and more.

The Big Web Show features special guests on topics like web publishing, art direction, content strategy, typography, web technology, and more. It’s everything web that matters.

Sarah Parmenter Photo by Pete Karl II.

In Defense of Descendant Selectors and ID Elements

Except when I occasionally update Designing With Web Standards, I quit writing hands-on, nuts-and-bolts stuff about CSS and HTML years ago. Publishing abhors a vacuum: other designers and developers took my place. For the most part, this has been a good thing—for them and for our industry. The best writers about code have always been those who spend 25 hours of every day up their necks in it, as I used to. While folks like me migrate into strategic or supervisory roles (providing us with new places to innovate and new things to write about), a new generation of code crafters is making new discoveries and sharing new teachings. Ah, the magical circle of life.

But amid the oodles of resulting goodness, I find occasional stinkers. Take the notion, now concretizing into dogma, that id should almost never be used because it has “too much specificity,” and that class names are always preferable. Respectfully, I call bunk.

To my knowledge, this notion comes out of Nicole Sullivan’s brilliant Object Oriented CSS, an approach for writing HTML and CSS that is designed to scale on sites containing thousands of pages, created by dozens of front-end developers over a period of years, generally with no rules or style guide in place (at least no rules or style guide until it is too late). On sites like these—sites like Amazon or Facebook that are hosed from the get-go thanks to too many cooks and no master chef—the use of structural id and descendant selectors can be problematic, especially when inept coders try to overwrite an id-based descendant selector rule by creating ever-more-specific descendant selector rules.

In this particular (and rare) circumstance, where dueling developers have added rule after rule to a huge, shapeless style sheet that is more of an archeological artifact than a reasonable example of modern code, Nicole’s admonition to avoid descendant selectors based on id is probably wise. If you have the misfortune to work on a huge, poorly developed site where you will never have permission to refactor the templates and CSS according to common sense and best practices, you may have to rely on class names and avoid descendant selectors and ids.

But under almost any other circumstance, properly used ids with descendant selectors are preferable because more semantic and lighter in bandwidth.

The way I have always advocated using id, it was simply a predecessor to the new elements in HTML5. In 2000, we wrote div id="footer" because we had no footer element, and we wanted to give structural meaning to content that appeared within that div. Today, depending on the browsers and devices people use to access our site, we may well have the option to use the HTML5 footer element instead. But if we can’t use the HTML5 element, there is nothing wrong with using the id.

As for descendant selectors, in a site not designed by 100 monkeys, it is safe to assume that elements within an id’d div or HTML5 element will be visually styled in ways that are compatible, and that those same elements may be styled differently within a differently id’d div or HTML5 element. For instance, paragraphs or list items within a footer may be styled differently than paragraphs or list items within an aside. Paragraphs within a footer will be styled similarly to one another; the same goes for paragraphs within an aside. This is what id (or HTML5 element) and descendant selectors were made for. Giving every paragraph element in the sidebar a classname is not only a needless waste of bandwidth, it’s also bad form.

Say it with me: There is nothing wrong with id when it is used appropriately (semantically, structurally, sparingly). There is plenty wrong with the notion that class is always preferable to descendant selectors and semantic, structural ids.

Please understand: I’m not disparaging my friend Nicole Sullivan’s Object Oriented CSS as an approach to otherwise unmanageable websites. No more would I disparage a steam shovel for cleaning up a disaster site. I just wouldn’t use it to clean my room.

I’ll be discussing code and all kinds of other things webbish with Chris Coyier and Dave Rupert on the Shoptalk podcast today. Meanwhile, let me know what you think. And don’t forget November 30th is the sixth international celebration of Blue Beanie Day in support of web standards. Wherever you may stand on the great id debate, please stand with me and thousands of others this November 30th.

Lawson on picture element

Those eager to bash Hixie and the WHATWG are using the new spec as if it were a cudgel; “this is how you deal with Hixie and WHATWG” says Marc Drummond. I don’t think that’s productive. What is productive is the debate that this publication will (hopefully) foster.

Bruce Lawson’s personal site: On the publication of Editor’s draft of the element.