99.9% of Websites Are Obsolete

99.9% of Websites Are Obsolete

An excerpt from Forward Compatibility: Designing & Building With Standards

By Jeffrey Zeldman
Digital Web Magazine

September 2002

An equal opportunity disease afflicts nearly every site now on the Web, from the humblest personal homepages to the multi-million-dollar sites of corporate giants. Cunning and insidious, the disease goes largely unrecognized because it is based on industry norms. Though their owners and managers may not know it yet, 99.9% of all websites are obsolete.

These sites may look and work all right in mainstream, desktop browsers whose names end in the numbers 4 or 5. But outside these fault-tolerant environments, the symptoms of disease and decay have already started to appear.

In the latest versions of Microsoft Internet Explorer, Netscape Navigator, and Mozilla (the Open Source, Gecko-based browser whose code drives Netscape Navigator, CompuServe, and other browsing environments), carefully constructed layouts have begun falling apart and expensively engineered behaviors have stopped working. As these leading browsers evolve, site performance continues to deteriorate.

In off-brand browsers, in screen readers used by people with disabilities, and in increasingly popular non-traditional devices from Palm Pilots(TM) to web-enabled cell phones, many of these sites have never worked and still don't, while others function marginally at best. Depending on needs and budget, site owners and developers have either ignored these off-brand browsers and devices or supported them by detecting their presence and feeding them customized markup and code—a practice the industry calls "versioning."

While off-brand versions typically treat users of sophisticated browsers like Opera to a diminished experience vis-à-vis their Explorer and Netscape-using counterparts, wireless versions fare still worse. Many rely on poorly supported wireless markup languages that are already obsolete.

These practices waste time and money. Neither commodity has ever been abundant; both have been in especially short supply since the Western Economy began its millennial downturn. Worse still, these costly practices fail to solve the problem. Sites are still broken. Users are still locked out.

Backward thinking

Peel the skin of any major site, from Amazon to Microsoft.com, from Sony to ZDNet. Examine their tortuous non-standard markup, their proprietary ActiveX and JavaScript (often including broken detection scripts), and ill-conceived use of Cascading Style Sheets—when they use CSS at all. It's a wonder such sites work in any browser.

They work in yesterday's mainstream browsers because the first four to five generations of Netscape Navigator and Microsoft Internet Explorer did not merely tolerate non-standard markup and browser-specific code; they actually encouraged sloppy authoring and proprietary scripting in an ill-conceived battle to own the browser space.

Often, non-standards-compliant sites work in yesterday's browsers because their owners have invested in costly publishing tools that accommodate browser differences by generating multiple, non-standard versions tuned to the biases of specific browsers and platforms. This practice taxes the dial-up user's patience by wasting bandwidth on code forking, deeply nested tables, spacer pixels and other image hacks, and outdated or invalid tags and attributes.

At the same time, these multiple versions squander the site owner's bandwidth at a cost even the bean counters may be at a loss to calculate. The bigger the site and the greater its traffic, the more money gets wasted on server calls, redundancies, image hacks, and unnecessarily complex code and markup.

What Yahoo looks like—as plain as an Amish coat.

What makes Yahoo look that way—convoluted markup and code.

Yahoo's front page is served millions of times per day. Each byte wasted on outdated HTML design hacks is multiplied by an astronomical number of page views, resulting in gigabytes of traffic that tax Yahoo's servers and add Pentagon-like costs to its overhead.

If Yahoo would simply replace its deprecated, bandwidth-gobbling <font> tags with bandwidth-friendly CSS, the cost of serving each page would greatly diminish, and the company's profits would consequently rise. So why hasn't Yahoo made the switch?

We can only conclude that the company wishes its site to look exactly the same in 1995-era browsers that don't support CSS as it does in modern browsers that do. The irony is that no one beside Yahoo's management cares what Yahoo looks like. The site's tremendous success is due to the service it provides, not to the beauty of its visual design (which is non-existent).

That this otherwise brilliant company wastes untold bandwidth to deliver a look and feel no one admires says everything you need to know about the entrenched mindset of developers who hold "backward compatibility" in higher esteem than reason, usability, or their own profits.

What do developers mean by "backward compatibility?" They mean using non-standard, proprietary (or deprecated) markup and code to ensure that every visitor has the same experience, whether they're sporting Netscape Navigator 1.0 or IE6. Held up as a Holy Grail of professional development practice, "backward compatibility" sounds good in theory. But the cost is too high and the practice has always been based on a lie.

There is no true backward compatibility. There is always a cut-off point. For instance, neither Mosaic (the first visual browser) nor Netscape 1.0 support HTML table-based layouts. By definition, then, those who use these ancient browsers cannot possibly have the same visual experience as folks who view the Web through later browsers like Netscape 1.1 or MSIE2.

Developers and clients who strive for backward compatibility inevitably choose a "baseline browser" (say, Netscape 3) beyond which they will make no effort. To support that baseline browser and those that succeeded it, developers layer their markup with a series of browser-specific, non-standard hacks and workarounds that add weight to every page. At the same time, they write multiple scripts to accommodate the browsers they've chosen to support, and use browser detection to feed each browser the code it likes best. In so doing, these developers further increase the girth of their pages, pump up the load on their servers, and ensure that the race against perpetual obsolescence will continue until they run out of money or go out of business.

While some companies undercut their own profitability trying to ensure that even the oldest browsers see their sites exactly as new browsers do, others have decided that only one browser matters. In a misguided effort to reduce expenses, an increasing number of sites are designed to work only in Internet Explorer, and sometimes only on the Windows platform, thus locking out 15% to 25% of their potential visitors and customers.

We won't pretend to understand the business model of a company that would say no to up to a quarter of its potential customers. And the sheer number of customers lost by this myopic approach should boggle the mind of any rational business owner. According to statistics compiled by NUA Internet Surveys (http://www.nua.ie/surveys/), over 540 million people used the Web as of February 2002. You do the math.

Say you don't mind losing up to 25% of the people who choose to visit your site. The "IE-only" approach still makes no sense, as there's no guarantee that IE (or even desktop browsers as a category) will continue to dominate web space.

Some years before this book was written, Netscape's Navigator browser enjoyed a market share greater than Microsoft's Internet Explorer does today. At the time, conventional wisdom held that Netscape's was the only browser that mattered, and developers coded accordingly. Untold millions of dollars later, the market changed. Netscape-only sites were dumped in the landfill beside the Information Superhighway.

Could the same fate lie in store for IE-only sites? Inconceivable as it seems, there's simply no telling. On the Web, the only constant is change. Factor in the increasingly widespread use of non-traditional Internet devices, and the notion of designing to the quirks of any individual desktop browser at the expense of all other browsers and devices starts looking like the brain-dead business decision it is.

Besides, as this book will show, standards make it possible to design for all browsers and devices as easily and quickly as for just one. Between the spiraling cost of backward compatible versioning and the futile short-sightedness of building for a single browser, web standards provide the only approach to development that makes a lick of sense.

Neither money-wasting versioning techniques nor the deliberate decision to support only one browser or platform will help today's sites work in tomorrow's browsers or thrive in the ever-changing world beyond the desktop. If these practices continue, costs and complexities will only escalate until none but the largest companies can afford to build websites.

Microsoft won the Browser Wars but all of us temporarily lost something more important: the chance to create a usable, accessible Web built on common industry standards. We lost it when designers and developers, scrambling to keep up with production demands during the short-lived Internet boom, learned non-standard, browser-specific ways of creating sites, thus bringing us to our current pass whose name is obsolescence.

But the obsolescent period of web development is dying as you read these words, taking countless sites down with it. If you own, manage, design or build websites, the bell tolls for you.

The disease

Early in a computer programmer's education, he or she learns the phrase: "Garbage In, Garbage Out." Put simply, in the world of programming, if you write your code correctly, it works. If you write it incorrectly, it fails. Languages like C++ and Java don't merely encourage proper coding practices, they demand them.

Likewise, among the first things a graphic designer learns is that the quality of source materials determines the effectiveness of the end product. Start with a high resolution, high quality photograph, and the printed piece or web graphic will look good. Try to design with a low quality snapshot or low-resolution web image, and the end result won't be worth viewing. You can turn a high quality EPS into a suitably optimized web page logo, but you can't convert a low-resolution GIF into a high quality web, print, or TV logo. "Garbage in, garbage out."

But traditional mainstream browsers don't work the same way. Lax to the point of absurdity, they gobble up broken markup and bad JavaScript file links without a hiccup, in most cases displaying the site as if it were authored correctly. This laxity has encouraged front-end designers and developers to develop bad habits of which they are largely unaware. At the same time, it has persuaded middleware and backend developers to view technologies like XHTML, CSS, and JavaScript as contemptibly primitive.

Those who do not respect a tool are unlikely to use it correctly. Consider the following snippet, lifted from the costly e-commerce site of a company competing in a tough market, and reprinted here in all its warty glory:

The nonsensical "ont" tag is a typo for the deprecated font tag—a typo that gets repeated thousands of times throughout the site, thanks to a highly efficient publishing tool. That error aside, this markup may look familiar to you. It may even resemble the markup on your own site. In the context of this web page, all that's actually necessary is the following:

Combined with an appropriate rule on a linked style sheet, the simpler, more structural markup above will do exactly what the cumbersome, non-standard, invalid markup did, while saving server and visitor bandwidth and easing the transition to a more flexible site based on XML. The same e-commerce site includes the following broken JavaScript link:

Among other problems, the unquoted language attribute erroneously merges with the source tag. In other words, the browser is being told to use a non-existent scripting language ("JavaScript1.1src"). By any rational measure, the site should fail, alerting the developers to their error and prompting them to fix it pronto. Yet until recently, the JavaScript on this site worked in mainstream browsers, thus perpetuating the cycle of badly authored sites and the browsers that love them. Little wonder that skilled coders often view front-end development as brain-dead voodoo unworthy of respect or care.

But as newer browsers comply with web standards, they are becoming increasingly rigorous in what they expect from designers and developers, and thus increasingly intolerant of broken code and markup. "Garbage in, garbage out" is beginning to take hold in the world of browsers, making knowledge of web standards a necessity for anyone who designs or produces websites.

The damage is not irreparable. We can design and build websites a better way that works across numerous browsers, platforms, and devices, solving the problems of built-in obsolescence and user lockout while paving the way toward a far more powerful, more accessible, and more rationally developed Web.

The cure to the disease of built-in obsolescence may be found in a core set of commonly supported technologies collectively referred to as "web standards." By learning to design and build with web standards, we can guarantee the forward compatibility of every site we produce.

"Write once, publish everywhere," the promise of web standards, is more than wishful thinking: it is being achieved today, using methods we'll explore in this book. But while today's leading browsers finally support these standards and methods, the message has not yet reached many working designers and developers, and new sites are still being built on the quicksand of non-standard markup and code. This book hopes to change that.

The cure

After a long struggle pitting designers and developers against the makers of leading browsers, we can finally employ techniques that guarantee the appearance and behavior of our sites, not simply in one manufacturer's browser, but in all of them.

Hammered out by the members of the World Wide Web Consortium (W3C) and other standards bodies, and supported in current browsers developed by Netscape, Microsoft, and other companies, technologies like Cascading Style Sheets (CSS), XHTML, ECMAScript (the standard version of JavaScript) and the W3C DOM enable designers to:

At last attain precise control over layout, placement, and typography in graphical desktop browsers.
Develop sophisticated behaviors that work across multiple browsers and platforms.
Comply with accessibility laws and guidelines without sacrificing beauty, performance, or sophistication.
Redesign in hours instead of days or weeks, reducing costs and eliminating grunt work.
Support multiple browsers without the hassle and expense of creating separate versions, and often with little or no code forking.
Support non-traditional devices, from wireless gadgets and web-enabled cell phones fancied by teens and executives to Braille readers and screen readers used by those with disabilities—again without the hassle and expense of creating separate versions.
Deliver sophisticated printed versions of any web page without creating separate "printer-friendly" page versions or relying on expensive proprietary publishing systems to create such versions.
Separate style from structure and behavior, delivering creative layouts backed by rigorous document structure and facilitating the re-purposing of web documents in advanced publishing workflows.
Transition from HTML, the language of the Web's past, to XML, the language of its future.
Ensure that sites so designed and built will work correctly in today's standards-compliant browsers and perform acceptably in old browsers (even if they don't render pixel-for-pixel exactly the same way in old browsers as they do in newer ones).
Ensure that sites so designed will continue to work in tomorrow's browsers and devices, including devices not yet built or even imagined. This is the promise of forward compatibility.
...And more, as this book will show.

Before we can learn how standards achieve these goals, we must examine the old-school methods they're intended to replace, and find out exactly how the old techniques perpetuate the cycle of obsolescence. Chapter 2 reveals all.

Jeffrey Zeldman is the Principal of Happy Cog Studios, a Web design agency and consultancy, and the author of Taking Your Talent to the Web (New Riders, 2001). He is group leader for The Web Standards Project, and Creative Director of A List Apart, a magazine for people who make Web sites.