This chapter is from the book

This chapter is from the book

Web standards hold the key to accessible, cost-effective web design and development, but you wouldn't know it from surveying significant commercial and creative sites of the past few years. In this chapter, we'll explore some of the reasons why web standards have not yet been incorporated into the normative practice of all design shops and in-house web divisions and are not yet obligatory components of every site plan or request for proposal.

If you would prefer to read web standards success stories, turn to Chapter 4, "XML Conquers the World (And Other Web Standards Success Stories." If you're sold on standards and are ready to roll up your sleeves, skip ahead to Chapter 5, "Modern Markup." But if you need help selling standards to your colleagues—or if you simply want to understand how an industry can attain standards without using them—this chapter is for you.

Lovely to Look At, Repulsive to Code

IN mid-2002, with six others from the new media community, I served on the judging committee of the Eighth Annual Communication Arts Interactive Awards (www.commarts.com), arguably the most prestigious design competition in the industry. The sites and projects submitted in competition were among the year's most skillfully developed and designed.

We judges initially spent 10 weeks reviewing thousands of websites and CD-ROMs, narrowing the field to hundreds of finalists from which fewer than 50 would be selected as winners. The final judging took place in the Bay Area, where the seven of us were sequestered for a week. Until winners were chosen, we could not leave. At week's end, we had chosen 47 winning projects and had thereby been released from bondage.

To celebrate the end of the judging (and with it, my newfound freedom), I met a San Francisco friend for dinner. The competition intrigued my pal, who knew a little something about web development himself.

My friend asked, "Did you take off points if the sites were not standards-compliant?"

I blinked. "None of them were standards-compliant," I said.

It was a fact. Of thousands of submitted sites, not one had been authored in valid, structural HTML. Many of these sites were visually arresting [3.1] and skillfully programmed [3.2]; several offered compelling, well-written content; and a few were startlingly original. But not one had a clue about valid structural markup, compact CSS, or standards-based scripting.

none 3.1 Team Rahal, Inc. (www.rahal.com), one of Team Rahal, Inc.websitesTeam Rahal, Inc.the winners of the Eighth Annual Communication Arts Festival, is beautiful, impressive, and nonstandards-compliant.

More than half the submitted sites had been developed entirely in Flash. Most of the rest worked only in 4.0 browsers, only in IE4, or only in Netscape 4. A few worked only in Windows. Of the hundreds of finalists, most of them lavishly (and expensively) produced, and each of them in its own way representing the industry's best professional efforts, not one had the slightest use for web standards.

Common Goals, Common Means

The websites submitted to Communication Arts were wildly diverse in their creative and marketing objectives, but most shared certain underlying goals—the same goals as your sites and mine. We all want our sites to attract their targeted audience, encourage participation, be easy to understand and use, and say all the right things about our organization, product, or service, not only in words, but also in the way the site looks and works.

Most of us would like to get the best value for the money in our budgets. We want our sites to work for as many people and in as many environments as possible. We hope to avoid bogging down in browser and platform incompatibilities and to stay at least one jump ahead of the swinging scythe of technological change.

Most of us hope to create a site that will work well into the future without continual, costly technological tinkering as described in Chapter 2, "Designing and Building with Standards." We would rather spend our limited time updating content and adding services than recoding our sites every time a new browser or device comes along.

Standards are the key to achieving these goals. So why haven't they taken the development community by storm?

Perception Versus Reality

For one thing, as with accessibility (see Chapter 14, "Accessibility Basics"), many designers hold the mistaken belief that web standards are somehow hostile or antithetical to the needs of good graphic design. For another, those who create standards are not in the business of selling them; the visually and architecturally pedestrian sites of W3C or ECMA [3.3] hold little inspirational appeal for graphic stylists and consumer-oriented designers. And the unprofessional appearance of W3C or ECMA does little to combat the myth that standards are antithetical to visual design. Only beautifully designed sites that use standards [3.4] can overturn that false perception.

none 3.3 ECMA (European Computer Manufacturers Association) is a bona fide standards body and ECMA (European Computer Manufacturers Association)European Computer Manufacturers Association. ECMAwebsitesECMAhome to many great minds. Unfortunately, none of those great minds possess even the barest competence in consumer-friendly writing, graphic design, or site architecture. Thus, the ECMA site (www.ecma.ch) is unlikely to inspire designers to learn about ECMAScript or other standards. (Contrast it with Figures 3.1 and 3.2, which represent the kind of appearance that inspires visual designers. You'll read more about ECMA later in this chapter.)

none 3.4 Kaliber 10000 (K10k), an avidly Kaliber 10000 (K10k)websitesK10kread design portal (www.k10k.net), is constructed with valid XHTML, CSS, and the W3C Document Object Model (DOM). Although not the first to embrace these standards, K10k's use of them is important, for it shows the design community that standards can support good graphic design.

Then, too, designers and developers who've taken the time to learn the Heinz 57 varieties of proprietary scripting and authoring might see little reason to learn anything new—or might be too busy learning JSP, ASP, or .NET to even think about changing their fundamental front-end techniques. Those who depend on WYSIWYG editors to do their heavy lifting have a different reason for not using standards. Namely, they depend on WYSIWYG editors; therefore, they're likely unaware that leading WYSIWYG editors now support standards. Many highly skilled developers use WYSIWYG tools like Dreamweaver and GoLive, of course, but so do many semi-skilled workers who would be powerless to create even a basic web page if denied access to said tools.

Finally, it is only relatively recently that mainstream browsers have offered meaningful standards compliance. Many web professionals are so used to doing things the hard way that they haven't noticed that browsers have changed. Let's examine this last reason first.