The Trouble with Standards
- Lovely to Look At, Repulsive to Code
- 2000: The Year That Browsers Came of Age
- Too Little, Too Late?
- Bad Browsers Lead to Bad Practices
- Confusing Sites, Bewildering Labels
- The F Word
- Compliance Is a Dirty Word
This chapter is from the book
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 most big commercial sites. In this chapter, we’ll explore some of the reasons 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’d prefer to read web standards success stories, turn to Chapter 4. If you’re sold on standards and are ready to roll up your sleeves, skip ahead to Chapter 5. But if you need help selling standards to your colleagues, this chapter is for you.
Lovely to Look At, Repulsive to Code
In mid-2002, with six other new media designers, I served on the judging committee of the 8th 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.
)
)
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.
Little has changed since then. The 11th Annual Awards (www.commarts.com/CA/interactive/cai05) held in 2005 mostly featured wonderfully creative but non-standards-related stuff like the Borders GiftMixer 3000 [3.3].
)
Common Goals, Common Means
The websites submitted to Communication Arts are wildly diverse in their creative and marketing objectives, but most share 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 the continual, costly technological tinkering described in Chapter 2. 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 design community by storm?
Perception Versus Reality
For one thing, as with accessibility (see Chapter 14), 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 pedestrian sites of the W3C [3.4] or Ecma (www.ecma-international.org) hold little inspirational appeal for graphic stylists and consumer-oriented designers. Such sites’ lack of style does little to combat the myth that standards are antithetical to visual design. Only beautifully designed sites that use standards [3.5] can overturn that perception.
)
)
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. Thus, unless they do a lot of extracurricular reading, they may be unaware that leading WYSIWYG editors now support standards. Many highly skilled developers use WYSIWYG tools like Dreamweaver, of course, but so do some semi-skilled workers who would be powerless to create even a basic web page if denied access to said tools.
Finally, it is only in the past few years that mainstream browsers have offered meaningful standards compliance. Many web professionals are so used to doing things the hard way, they haven’t noticed that browsers have changed. Let’s examine this last reason first.