Eric Meyer still doesn’t get it. He wants anything that hasn’t been approved out of HTML, or there will be hell to pay!

Of course, the theorist in me is quivering in outrage. The browser-wars veteran isn’t too thrilled either. For years, we heard Microsoft and Netscape say things like “standards are secondary to customer demands” and “standards aren’t as useful as the cool new proprietary features we’re adding”. These things need not be inimical to standards support. They should not require a breaking of standards.

I’m a browser wars veteran, too, and there’s a big difference between supporting standards and implementing only the standards. Fortunately, there’s actually somebody at the usually insane Web Standards Project who Gets It:

Overall, though, it’s not that big a deal. Safari does an excellent (not perfect) job of supporting the various HTML, XHTML, and CSS specs as they’re written and ultimately, that’s what’s most important. If developers don’t want to use the extensions, they don’t have to. The vision that the WaSP has been most adamant about is that developers should be able to build sites that conform to the published specs and have them Just Work^TM in every browser. If browsers want to support additional proprietary extensions on top of that, they’re free to do so and the rest of us are free to ignore them.

Yes! Somebody who actually acts like they built a site between 1996 and 1999! The problem then was twofold: content authors targeting code to one browser and one browser only, and browsers defining the same term in different ways.

The first case was much more annoying from a Web user’s perspective (hello, remember when the Web was for creators and users, not browser makers, user agents, and standards gurus?). That was the source of the dreaded “This site works best in StupidBrowser 4” badges. The problem there was authors who thought their latest trick was more important than letting users read their content. This seems to be a stage people go through when they come to the Web, and most content authors have now gone through it, except for Microsoft-happy CTOs, who are by definition morons. The solution was education about cross-browser compatibility. A tool to achieve that was standards compliance, but the tool was not the be all and end all–it was a means (conform to HTML 4 elements only) to an end (your content works for lots of people).

The second problem was more annoying from a content author’s perspective, particularly if you were trying to be good about cross-browser compatibility. Different browsers treated whitespace, width, and borders differently. Trying to get your site to look the same in multiple browsers was an exercise in frustration.

Sounds familiar, doesn’t it? That’s because, thanks to innovation in Standards coming from a group of purists and people who want to use HTML for data interchange rather than browser authors and content creators with wide-ranging feedback, standards are hard to implement and ambiguous in application. Even the “reference browser” provided by the W3C can’t keep up.

Ironically, if you code to HTML 4.01 and use the Bad Old Way of doing things, the latter problem is gone from modern browsers. All of them basically support the Netscape 4 way of doing things identically. It’s when you do it the New Good Way that suddenly simple things just fail miserably (try getting side-by-side floating boxes within a larger box that scale in width working in IE 5 through 6 without browser detection, I dare ya–and that’s just one browser).

Simply adding extensions that other browsers don’t support, as long as content authors don’t use them in ways that exclude people from sites, just isn’t a big deal. It never was. IE’s addition of the MARQEE tag never affected me, as few people put important information in it, and I never had to use it. Netscape’s handling of whitespace in table cells affected me far more, and table cells and whitespace are all standard components of HTML documents.

Dave Hyatt has shown the way: innovate in response to developer demand, do so in a way that is easy to implement, consult with other browser makers to make sure you and they have the same definition of “easy”, do so in a way that older browsers can safely ignore, and contribute those innovations back to the standards body for blessing.

We need to get HTML back on course, rather than becoming a weird mishmash of automated data interchange and cataloging librarian nirvana RDF hell. The Right Tool for the Right Job. HTML is the Right Tool for written Web document exchange. It is the Wrong Tool for auto-descriptive frameworks or intelligent agents. Let’s focus on that, and actually make content authors’ and hence Web users’ lives easier.