wessman
September 12th, 2002, 05:40 PM
Are 99.9% of Websites Obsolete? |
| from the nah-its-just-us dept. |
| posted by CmdrTaco on Wednesday September 11, @11:08 (internet) |
| http://slashdot.org/article.pl?sid=02/09/11/148236 |
+--------------------------------------------------------------------+
citizenkeller writes "[0]Zeldman is at it again: " Though their owners
and managers may not know it yet, 99.9% of all websites [1]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.""
Discuss this story at:
http://slashdot.org/comments.pl?sid=02/09/11/148236
Links:
0. http://www.zeldman.com/
1. http://www.digital-web.com/features/feature_2002-09.shtml
99.9% of Websites Are Obsolete
An excerpt from Forward Compatibility: Designing & Building With Standards
http://www.digital-web.com/features/feature_2002-09.shtml
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.
:sw
| from the nah-its-just-us dept. |
| posted by CmdrTaco on Wednesday September 11, @11:08 (internet) |
| http://slashdot.org/article.pl?sid=02/09/11/148236 |
+--------------------------------------------------------------------+
citizenkeller writes "[0]Zeldman is at it again: " Though their owners
and managers may not know it yet, 99.9% of all websites [1]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.""
Discuss this story at:
http://slashdot.org/comments.pl?sid=02/09/11/148236
Links:
0. http://www.zeldman.com/
1. http://www.digital-web.com/features/feature_2002-09.shtml
99.9% of Websites Are Obsolete
An excerpt from Forward Compatibility: Designing & Building With Standards
http://www.digital-web.com/features/feature_2002-09.shtml
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.
:sw