Menu

Grassroots Enforcers: The Web Standards Project

April 10, 2000

Edd Dumbill

Unlike many industries, the Web has no legal or governmental enforcement of standards. While this freedom is great for innovation, when vendors start engineering for the "Wow!" factor rather than accessibility, the users are the ones who lose. However, the Internet always fights back, and a loose-knit collection of individuals have banded together in the form of the Web Standards Project to ensure that users don't lose out. I talked to Jeffrey Zeldman, leader of the group, about the project and their views on XML standards.

ED: Who are the Web Standards Project?

JZ: The Web Standards Project is a grassroots coalition of Web developers and users fighting for standards on the Web. Our goal is to persuade browser makers that support for W3C standards is in everyone's interest, including their own.

Upon our launch in 1998, we put forward a baseline proposal outlining the particular standards we believe must be fully supported in all browsers if the Web is to avoid continued fragmentation and problems with accessibility. Those standards include:

  • Structural Languages: HTML 4.0, XML 1.0
  • Presentation Languages: Cascading Style Sheets 1, Cascading Style Sheets 2, XSL (under development)
  • Object Models: Document Object Model 1 Core HTML/XML
  • Scripting: ECMAScript (the "official" version of JavaScript)

Also included are emerging standards, such as those for television-based and PDA-based browsers.

These standards were created by W3C (with the exception of ECMAScript) with the intention of balancing the needs of designers for a sophisticated set of presentation and interactive features against the desire to make the Web accessible to the largest possible number of browsers (and other client devices) and environments.

On a practical economic note, the WaSP estimates that lack of complete support for standards adds 25% to the cost of Web development, as designers and programmers are forced to create hacks and workarounds to compensate for the variously incompatible browsing environments. These hacks and workarounds, in turn, break down in the next browser version. The entire process is costly, stupid, and counterproductive.

In addition, since there is never enough time to code every possible workaround, budgetary and time restraints guarantee that some people will not be able to use a given Web site. This hurts a wide variety of Web users, from the executive using a Web-enabled cell phone to a visually impaired senior citizen.

Thousands of Web developers and users have joined the WaSP to voice their concern and support.

ED: Why did the Web Standards Project start?

JZ: Developers got fed up with the insanity.

Can you imagine any other industry dealing with incompatibilities like this? Let alone trying to grow?

The Internet is the fastest-growing economic sector, and it's being built without a stable foundation. The W3C designed the blueprints, and the browser makers said, "Great! Thanks!" and then started building whatever they felt like building.

It was the release of the 4.0 browsers, with their much-trumpeted (and proprietary, and totally incompatible) DHTML implementations, that really made Web developers see red.

Shortly after the release of those browsers, Glenn Davis and George Olsen decided to protest, and they asked a bunch of us if we would be interested in organizing a group around that purpose. Nearly everyone contacted said yes. And here we are.

ED: Why should end-users care about standards?

JZ: People who use the Web do care, though they might not use words like "standards," and they probably don't know the "W3C" from the WWF. (Nor should they have to.)

People care when they can't read text on a page. They care when their browser crashes, or they're bumped off a site because their browser or platform is incompatible. They care when they want to read information, or participate in a discussion on a message board, or save $100 on airline tickets, and they can't do it because of flawed and incompatible brower implementations. Millions of disabled people care when they can't even begin to access huge chunks of the Web.

They may not know why it's happening, but they certainly feel the effects. Nobody enjoys being locked out, and nobody should be subjected to that experience. Especially in a worldwide communications medium that was designed to be accessible to all.

When you look at a bungled e-commerce transaction, that's merely human frustration (and millions of dollars in lost revenues). But when it gets down to denial of access -- when people cannot get information they desperately need -- that's more than frustration, more than a financial problem. It's a serious moral issue. Accessibility is not a theory. It's a human right. Lack of support for standards is to blame.

ED: Are you having an effect on the vendors? Do you have an example?

JZ: We've definitely had a positive effect.

In 1998, we learned that Netscape had a standards-compliant rendering engine (now known as "Gecko") waiting in the wings -- a rendering engine that was capable of fully supporting HTML 4.0, CSS-1, XML 1.0, JavaScript/ECMAScript, and the W3C DOM.

We also learned that Netscape had no intention of putting this standards-compliant rendering engine to immediate use in their browser. Due to the competitive market pressures, they were simply going to release a Version 5.0 browser with "new and improved" features (but no serious standards compliance).

The WaSP organized a petition drive, collected thousands of signatures, and helped persuade Netscape to build the next version of Navigator/Communicator around this standards-compliant Gecko rendering engine. Netscape agreed. It's taken a long time, and Netscape has lost considerable market share in the process, but they did the right thing and the Web is about to change for the better as a result. Would this have happened anyway, if the WaSP had not pressured Netscape? Who knows? We did pressure them, and they did change their business plans.

ED: Why do you view the DOM as so vital?

JZ: The Document Object Model is an orchestra conductor, and right now the Web is an orchestra without a conductor. It's a miracle if the players manage to stay in tune, much less keep tempo with each other -- or even play the same music. The Document Object Model allows Web sites to offer sophisticated interactivity. Without that Document Object Model, interactivity is still a hit-or-miss proposition. Should I use Netscape 4 layers? The Microsoft Explorer 4 DOM for Windows? If I want to create anything interactive or transactional, I basically have to code my site several different ways -- writing to the quirks of individual browsers -- and use JavaScript to detect which browser you're using, and make sure you get the right set of quirks.

There are programmers right now who make a handsome living because they know every quirk and kink of every incompatible browser out there. But if all those incompatibilities were to vanish, these folks would still be in demand, because they would be freed from the bondage of coding workarounds, and liberated within a very different Web space, where they could begin to build sophisticated applications that work for everyone.

ED: How does the XML world compare to the HTML world for standards compliance?

JZ: You can build a website using nothing but a given version of HTML, and have a working website. You can build a browser that claims to support HTML, and verify that claim pretty easily. XML is more complex, it interacts with other standards in complex ways, and even well-meaning and informed people can disagree violently about "what is XML" or "what is XML support." Which is why The Web Standards Project: (a) asks for 100% support for an XML recommendation with a version number; and (b) demands full support for five key standards, because -- with the possible exception of HTML -- the rest of these standards do not exist in a vacuum. They interact with and support each other.

ED: Which aspects of XML compliance worry you most?

JZ: My "XML compliance" worries aren't technical. They're as simple as can be, because they have version numbers attached to them. My understanding of "XML compliance" means full support of the XML 1.0 Recommendation, together with full support for associated standards (DOM 1 Core and ECMAScript).

I worry that browser makers will partially support XML -- or even just partially support "experimental implementations" of XML -- and claim to be delivering XML support. What we are asking for is 100% support for XML 1.0, which has been a stable recommendation since 1998. Do we need more than that? Sure. We need that, plus the DOM, plus ECMAScript, plus CSS-1 and HTML 4. Partial support of XML without the DOM is a completely meaningless gesture, and may be worse than no support at all.

If I built a browser that supported <h1> and <p> and nothing else, would I claim to support HTML? Of course not. Why do browser makers think they can offer bits and pieces of a complete standard, and call it "XML support?" They need to be called on this behavior, and that's what we're here for.

The W3C recommends standards. It cannot enforce them, and it certainly is not about to throw public tantrums over non-compliance. So we do that job.