Excerpt from the book:

Designing With Web Standards

By Jeffrey Zeldman

99.9% of Websites Are Obsolete

Backward Thinking

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

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

What Is Code Forking?

Code is the stuff programmers write to create software products, operating systems, or pretty much anything else in our digital world. When more than one group of developers works on a project, the code might "fork" into multiple, incompatible versions, particularly if each development group is trying to solve a different problem or bend to the will of a different agenda. This inconsistency and loss of centralized control is generally regarded as a bad thing.

As used in this book, code forking refers to the practice of creating multiple versions of incompatible code to cope with the needs of browsers that do not support standard ECMAScript and the DOM (see "The 'Version' Problem").

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

Hard numbers are hard to come by, but in general, if a site reduces its markup weight by 35%, it reduces its bandwidth costs by the same amount. An organization that spends $2,500 a year would save $875. One that spends $160,000 a year would save $56,000.

Yahoo's front page [1.3] is served millions of times per day. Each byte that is 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 [1.4] 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?

Peel Yahoo's skin (view Source), and you'll discover that the code and markup used to create this simple-looking website are unbelievably convoluted and perplexing.

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 nonexistent).

That this otherwise brilliant company wastes untold bandwidth to deliver a look and feel no one greatly 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.

Outdated Markup: The Cost to Site Owners Suppose the code and markup on one old-school web page weighs in at 60K. Say that, by replacing outdated <font> tags and other presentational and proprietary junk with clean, structural markup and a few CSS rules, that same page can weigh 30K. (In my agency's practice, we can often replace 60K of markup with 22K or less. But let's go with this more conservative figure, which represents bandwidth savings of 50%.) Consider two typical scenarios, detailed next.

T1 Terminator

Scenario: A self-hosted small business or public sector website serves a constant stream of visitors—several hundred at any given moment. After cutting its page weight in half by converting from presentational markup to lean, clean, structural XHTML, the organization saves $1,500 a month.

How it works: To serve its audience prior to the conversion, the self-hosted site requires two T1 lines, each of which is leased at a cost of U.S. $1,500 per month (a normal cost for a 1.544-megabit-per-second T1 line). After shaving file sizes by 50%, the organization finds it can get by just as effectively with a single T1 line, thus removing $1,500/month from its operating expenses. In addition to savings on bandwidth, there will also be fewer hardware expenses. The simpler the markup, the faster it's delivered to the user. The faster it's delivered, the less stress is placed on the server—and the fewer servers you need to buy, service, and replace. This is particularly true for servers that must cope with dynamic, database-driven content—that is, all commerce and most modern content sites.

Not every hosting company charges outrageous amounts for excess file transfers, of course. Pair.com, for instance, currently charges 1.5 cents a megabyte for overruns. A Pair-hosted small site with low traffic might save only $200/year. Larger sites with higher traffic have the most to save by reducing file sizes. Whether your site is large or small, visited by millions or just a handful of community members, the smaller your files, the lower your bandwidth, and the less likely you are to run afoul of your hosting company's file transfer costs. By the way, it's best to choose a hosting company that permits unlimited (also called "un-metered") file transfers rather than one that penalizes you for creating a popular site.

Bandwidth savings are only one advantage to writing clean, well-structured markup, but they're one that accountants and clients appreciate, and they hold as true for those who compress their HTML as they do for the rest of us.

Whereas 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–25% of their potential visitors and customers 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 because there's no guarantee that IE (or even desktop browsers as a category) will continue to dominate web space Some developers responded to this assessment with a self-satisfied shrug. The web was hot, hot, hot, and clients were willing to pay, pay, pay; so why should big web agencies worry about the high cost of multiple code and markup versions? Then the Internet bubble burst, web budgets shrank or froze, and agencies began downsizing or going under altogether. Suddenly, almost nobody could afford to fork over the cash for code forks.

While the industry was reeling from layoffs and closings, a new generation of browsers arrived that supported a common DOM—the one created by the W3C. What did this development mean? It meant versions were on the way out and a new era of standard-based design and development was finally at hand. And how did our economy-sobered industry respond to this long-desired news? By continuing to write code forks, developing for IE/Windows only, or switching to Macromedia Flash. For a business populated by visionaries, the web industry can be curiously myopic.

The creation of multiple versions of nonstandard markup and nonstandard code, each tuned to the nonstandard quirks of one browser or another, is the source of the perpetual obsolescence that plagues most sites and their owners. The goal posts are always receding, and the rules of the game are forever changing.

In addition to proprietary scripts, developers write presentational markup that doubles the bandwidth needed to view or serve a page while making that page less accessible to search engines and nontraditional browsers and devices. Such strategies often cause the very problem they were intended to solve: inconsistent rendering between one browser and another [1.1].

With multiple versions come ever-escalating costs and conundrums. "DHTML" sites produced to the proprietary (and incompatible) scripting specifications of Netscape 4 and IE4 don't work in most modern browsers. Should the site owner throw more money at the problem, asking developers to create a fifth or sixth version of the site? What if there's no budget for such a version? Many users will be locked out.

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, and users are still locked out.

Often, nonstandard-compliant sites work in yesterday's browsers because their owners have invested in costly publishing tools that accommodate browser differences by generating multiple, nonstandard versions tuned to the biases of specific browsers and platforms, as described earlier in "The 'Version' Problem." The 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.

I stumbled onto web standards after three years of designing sites the old-fashioned way, and it took me another five years to reach the understanding on which this book is based. You might disagree with any part of what I've said in these pages. I might disagree with some parts myself six months or two years from now. The point is not to bog down in differences or reject the whole because you're uncertain about one or two small parts. The point is to begin making changes that will help your projects reach the most people for the longest time, and often at the lowest cost.