Working together for standards The Web Standards Project

A response to Eric Ott and Al Sparber

THE WaSP HAS TAKEN SOME GRIEF lately, both for wanting things that we’ve asked for and for wanting things that we’ve never asked for.

All we’ve ever asked is for web developers and designers to have a choice: that if they want to create standards-compliant pages, the browsers will support them, as will the tools they use to create their sites.

When the WaSP first started, we made it clear in our FAQ that we weren’t asking browser makers to stop supporting, or even stop creating, proprietary tags. All we asked is that they, in addition, support designers and developers who chose to create standards-compliant code.

Now that the browser makers have listened, we’ve begun encouraging the tool makers to also allow designers and developers to create standards-compliant pages. Unfortunately, we’ve seen an overreaction from them that makes it clear that they think we’re asking for much, much more.

Try this experiment. Download a trial version of Dreamweaver from Macromedia’s web site (go ahead, it’s a good product, it won’t bite or anything). Open up a new web page, and type in “Hello, World!” Save it to disk.

Now look at the code. It’s clean, it’s straightforward, it’s great, except for one thing: it doesn’t validate. You cannot, out of the box, create a standards-compliant page with Dreamweaver, for the simple reason that the pages don’t include a DOCTYPE.

Next, go to Macromedia’s Dreamweaver Exchange site, and search on the word “doctype.” You’ll see a number of results. Choose one, download it, and install it into your copy of Dreamweaver. Now, create that “Hello, World!” page again, but this time, with a DOCTYPE.

Your page should now validate.

All we’ve asked Macromedia to do is ship Dreamweaver with the ability to create standards-compliant pages. It can’t be that difficult; as you’ve seen, the technology is already there.

In general, people don’t purchase WYSIWYG tools because they want to go in and change the code by hand. They buy these tools precisely so they can avoid that. Yes, you can add the DOCTYPE by hand, but people who buy WYSIWYG tools don’t want to have to that; their tool should do it for them.

Only a fraction of the people who buy Dreamweaver ever make it to the Exchange site, and only a fraction of those will ever download a DOCTYPE extension. If Macromedia shipped one with their product, it would automatically be available to everyone.

What’s so important about a DOCTYPE, anyway? Well, IE 5/Mac renders pages differently depending on whether a DOCTYPE exists, and which one you’re using if it does. And so does Netscape 6. IE6/Win will too, when it ships. In order to create pages that use these browsers to their fullest extent, you’ll need to have a DOCTYPE on your page.

We’re not demanding that the tool makers stop supporting deprecated tags, as some have said. We’re not asking them to stop creating tool-specific attributes. (Similarly, we never asked Microsoft to drop support for colored toolbars in IE; we just questioned if that was the best use of their developer effort instead of supporting compatibility with standards.) All we ask of the tool vendors is that they allow users the ability to create standards-compliant pages.

If a designer has the ability to create a site that supports standards, but chooses not to, the WaSP has no problem with that. We don’t know what your site logs look like, or your marketing plan, or your target audience. You do, and you should gear your site accordingly.

On the other hand, as just one example, the State of Texas now requires that all of its web sites support W3C standards. Federal regulations now require that all government web sites support accessibility, and supporting W3C standards gets you much of the way towards that goal.

Building a standards-compliant site does not mean that you have to switch to CSS or stop using FONT tags. For instance, a site that uses FONT tags and an HTML 3.2 DOCTYPE can be a perfectly valid, standards-compliant site. And if that’s what’s appropriate for that site’s audience, do it.

The problem isn’t just Macromedia. Adobe has also objected to the WaSP’s requests, with the excuse that much of GoLive’s power is accomplished by the addition of tool-specific attributes to tags. Once again, this isn’t something that the WaSP has a problem with, so long as GoLive users can, if they choose, do without those attributes.

The WaSP isn’t about requiring anyone to create standards-compliant code, or about rejecting older browsers, or about demanding that good tools stop being good. It’s about supporting designers and developers who want to make pages that support standards.

Adobe and Macromedia: you have good tools. There are people who want to use those tools. There are people who want to create standards-compliant pages. Why do you see these as two separate groups? Some of them are the same people, and they’d like to use your tools. Please help them become your customers.

Return to top

Post a Reply

Comments are closed.

All of the entries posted in WaSP Buzz express the opinions of their individual authors. They do not necessarily reflect the plans or positions of the Web Standards Project as a group.

This site is valid XHTML 1.0 Strict, CSS | Get Buzz via RSS or Atom | Colophon | Legal