Standard? What standard?
Authoring toolmakers and standards advocates disagree, even among themselves, about what constitutes a standards-compliant markup. The most stringent critics contend that the abundance of unwieldy workarounds found in tool-authored code invalidates it; others, willing to live with the extra code, are agitating for the toolmakers to add support for specific W3C technologies.
The toolmakers themselves say that their applications do support the key W3C recommendations and that they go beyond that to accommodate the older browsers that still account for a huge proportion of the Web's viewing audience.
"There's no question--we are standards compliant," Ott said. "The issue is with some of these emerging technologies, like XHTML, CSS 2 and accessibility. These are all things that are on people's radar right now, and we're working with different groups to make sure that all these new features are in the product."
Reflecting the needs of their customers, whose clients want to accommodate the broadest possible audience, Microsoft, Macromedia and Adobe characterise standards compliance as a journey rather than a destination, defending their insertion of bulky workarounds as a practical necessity.
"The standards are there as something to shoot for, but in terms of what people are trying to achieve, you want your output consistent with all the browsers out there," Hui said. "And if the browsers are not compliant, you have to do things in your code to make things display the way you want it to display."
Dealing with the Luddite factor
The prevalence of noncompliant browsers on the Web is no small problem for Web authors. While advocates have judged the latest browsers to be largely standards compliant, the older browsers persist in large numbers.
Macromedia, for example, said that 84 percent of its Dreamweaver users test their sites for Netscape's 4.x browsers, followed by 73 percent testing for IE 5.5. Sixty-six percent test for IE 5.0, 47 percent for IE 4.x, and 43 percent for Netscape 6.
In an indication of the longevity of old browsers on the Web, 23 percent of Dreamweaver users still test for Netscape's 3.x browser, which Netscape introduced in 1996. That is down sharply from 70 percent last year, when it was still the No. 1 browser Dreamweaver users tested. Opera, a browser with a smaller reach but a reputation for standards compliance, was tested by 8 percent of Dreamweaver users.
Standards advocates say the continued popularity of the authoring tools has created a world in which increasingly standards-compliant Web browsers are encountering few standards-compliant Web pages--at least by the stringent definitions put forth by WaSP members.
"I hand code, but I'm a dying breed," said Jeffrey Zeldman, group leader for WaSP. "At a recent Web conference I asked how many people in the audience hand-coded their Web sites. Five people out of a thousand raised their hands. Then I asked, 'Who uses Dreamweaver?' and the whole room raised their hands.
"These are all professionals, and if they're all using Dreamweaver, and it isn't generating standards-compliant markup and code, all the standards-compliant browsers in the world are not going to make the Web more standards compliant."
A question of relevance
Nevertheless, the new drive to improve the standards compliance of the authoring tools raises fundamental questions about the purpose of Web standards. WaSP's original rallying cry was that developers were saddled with the time-eating task of coding Web pages that would render properly in half a dozen different browsers--various versions from various software makers for various operating systems, none of which conformed to W3C recommendations.
But now the authoring tools do the time-consuming work, automatically spitting out code that renders properly on whatever browser a visitor might have. With authoring tools automating that ungrateful work, what's the point of Web standards?
Standards advocates point out two practical advantages to valid code, or code that would pass muster with the W3C Validation Service.
Standards-compliant code, they argue, is lightweight code. While authoring-tool markup is full of repetitious workarounds, standards-compliant code essentially writes once and runs anywhere--provided that "anywhere" is a standards-compliant browser.
"The authoring tools...make your pages bigger, straining your servers," Zeldman said. "If you have 10K of unnecessary code, and you have 100,000 visitors, your systems admin is going to need an extra server to handle the traffic."
A second practical reason to produce standards-compliant code has to do with federal regulations requiring Web pages to be accessible to people with disabilities. And standards-compliant code, advocates say, is accessible code.
"There is a strong business case for authoring tools that can support the production of accessible Web sites," Judy Brewer, director of the W3C's Web Accessibility Initiative, wrote in an e-mail interview. "Sites built with valid code, using universal design principles, are usable by a more diverse range of people and devices."
The W3C in February 2000 issued guidelines for authoring toolmakers to create more accessible code.
A Microsoft spokesman said the February 2000 guidelines came out too late for consideration in its FrontPage 2002 product.
The toolmakers are also under pressure from a federal law known as Section 508, which requires federal government Web sites to be accessible to people with disabilities.
Adobe described accessibility as "a top issue" for the company and said it was close to releasing a module that would make GoLive Section 508-compliant. Macromedia in May announced a partnership with UsableNet to provide an extension for Dreamweaver that verifies whether code is compliant with the law.
But the strictest of the standards advocates want the authoring toolmakers to go beyond accessibility. As part of their drive to get people to upgrade their browsers, these activists want the toolmakers and the Web authors who use the tools to offer Web surfers some bitter medicine, telling those with noncompliant browsers to come back with a compliant browser or look at a buggy page.
For example, the standard way to place an image file at the top left of a Web page is to create a style sheet that eliminates the margin at the top of the page. But the authoring tools will generate a number of tags to eliminate the gap, because Netscape 4 cannot read style sheets.
"We're saying it's just too bad about that 1997 browser," said WaSP's Zeldman. "If someone's using it, let there be a gap at the top of the page. Write standards-compliant code."
"There's no way you can get a page that works with every browser from the beginning of time," WaSP member Negrino agreed. "You have to worry about Netscape 4, 4.02, 4.5, and then you talk about supporting different platforms and Linux--the simplest way is to build Web sites that are standards compatible, and if your browser can't read them, that's your problem."
Pragmatists and idealists
Authoring toolmakers take a dim view of the WaSP's hard line.
"If you have a client with a million users visiting your Web site, no one is going to tell them to go away and get Netscape 6," said Macromedia's Ott. "You're trying to make money. And your clients are demanding compatibility."
Adobe agreed, stressing that the gap between the launch of browsers and their adoption was inherently slow.
"In reality, when new browsers come out, there's a certain lag time," Hui said. "People like my grandma, who uses the Internet--she doesn't have a clue about how to upgrade a browser. She uses what came with the computer. You definitely have a legacy problem--Tom's right about that--but I would disagree that you author to the latest standards, because you're essentially cutting out a lot of your audience."
Advocates predict that toolmakers eventually will come around to their point of view, just as browser makers have.
"Already they are realising that in the future, standards compliance is going to be a competitive feature," said Dori Smith, a programmer, WaSP member, and Negrino's wife and occasional co-author. "It's going to be one of those competitive checkboxes. As soon as that happens, they are going to want to do it. Both companies started off saying, 'We're not sure we're hearing developers saying they want this,' but now they're hearing a real groundswell."
