99.9% of web sites obsolete?

[Paul Taylor]

Dredged from Slashdot--an excerpt from "Forward Compatability: Designing and 
Building with Standards"

Here's the URL:
http://www.digital-web.com/features/feature_2002-09.shtml


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

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 
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:
<td width="100%"><ont face="verdana,helvetica,arial"
size="+1" color="#CCCC66"><span class="header"><b>Join now!
</b></span></ont></td>

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:
<h2>Join now!</h2>

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:
<script language=JavaScript1.1src="http://foo.com/Params.
richmedia=yes&etc"></script>

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.

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 
Riders.

-- 
Paul Taylor
Computer Coordinator
Salem-South Lyon District Library
9800 Pontiac Trail
South Lyon, MI 48178

248-437-6431 phone
248-437-6593 fax
http://south-lyon.lib.mi.us