X
Business

New front opens in Web standards war

Having persuaded browser makers to adopt common rules for displaying Web pages, standards advocates are now prodding companies that make Web authoring tools to comply too.
Written by ZDNET Editors, Contributor
Web standards advocates are declaring victory in their battle over browsers, but as they turn up the heat on their next adversary it's clear that their longstanding crusade on behalf of elegant design principles is far from over.

After years spent goading Netscape Communications and Microsoft into complying with guidelines recommended by the World Wide Web Consortium (W3C), standards proponents say they are turning their attention to companies that make Web authoring tools. Topping the hit list now are the likes of Macromedia and its popular Dreamweaver authoring tool; Adobe Systems and its GoLive product; and Microsoft again, for its low-end but widely used FrontPage software.

"None of the big tools--Dreamweaver, GoLive, FrontPage--none of them currently writes standards-compliant code," said Tom Negrino, author of numerous books about the Web and a member of the Web Standards Project, or WaSP.

The shift in standards enforcement marks a significant turning point in the adoption of common rules for displaying Web pages. Though Microsoft and Netscape have both released browser versions that conform with W3C recommendations, activists say they face a new problem: Almost nobody is producing Web pages written exclusively in standards-compliant code.

Standards proponents say such compliance promises significant advantages, such as conserving bandwidth with "lighter" code and the ability to provide access to Web surfers with disabilities, which the federal government requires of all its agencies. Nevertheless, standards efforts continue to be a source of friction in the development community, as pragmatists and idealists clash over the best way to implement them.

While few deny the benefits of full standards compliance, many argue that the switch to standards must come gradually, because millions of Web surfers still use old browsers that can't read the latest and greatest code. As a result, most Web developers continue to support outdated code, a task that has been made effortless by tools such as Dreamweaver, which automatically includes workarounds for older browser versions.

Now, however, some standards advocates are asking developers to do their part in convincing the technology laggards to upgrade--even at the risk of alienating un-savvy Web surfers who might be challenged or intimidated by the task of downloading and installing new software.

That effort is causing some tension with Web developers, who insist they, too, are eager for a more fully standards-compliant Web.

"For our Web developers, the No. 1 issue we see in our research is cross-browser compatibility," said Eric Ott, group product manager for Dreamweaver at Macromedia. "The browsers start off with standards but then build on top of that with their own bells and whistles. So developers pull their hair out trying to make things work in both browsers. It's really hard to get things to work across all the browsers in every environment, so moving towards standards is going to make things a lot easier for us."

Sam Hui, senior product manager for Adobe's GoLive tool, agreed, warning that patience, not brute force, was the only thing that could rid the Web of the older, noncompliant browsers.

"As Netscape changes its tune and Microsoft builds browsers closer to the standard, it certainly makes our job easier," Hui said. "It's much harder for us to take into account all these little variations than it would be to just create one standards-compliant browser. But the reality is that we don't live in that world yet."

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 characterize 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 realizing 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."

Editorial standards