99.9% of web sites obsolete?
ptaylor at tln.lib.mi.us
Wed Sep 11 19:14:07 EDT 2002
Dredged from Slashdot--an excerpt from "Forward Compatability: Designing and
Building with Standards"
Here's the URL:
And here's the text:
99.9% of Websites Are Obsolete
An excerpt from Forward Compatibility: Designing & Building With Standards
By Jeffrey Zeldman
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
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
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.
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
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
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.
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
(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
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.
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
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
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:
<td width="100%"><ont face="verdana,helvetica,arial"
size="+1" color="#CCCC66"><span class="header"><b>Join now!
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
Among other problems, the unquoted language attribute erroneously merges with
the source tag. In other words, the browser is being told to use a
measure, the site should fail, alerting the developers to their error and
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
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.
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
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
* 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.
Excerpted from Forward Compatibility: Designing & Building With Standards by
Jeffrey Zeldman, to be published by New Riders in early 2003. Copyright ©
2002-2003 by New Riders and Jeffrey Zeldman. Used by permission of New
Salem-South Lyon District Library
9800 Pontiac Trail
South Lyon, MI 48178
More information about the Web4lib