Be Careful What You Wish For..

Some Popular Myths

• The browsers don't support the standards so I can't either.
• Anyway, if I try to it'll take too much time and effort.
• All that really matters is how a site looks under Microscape..

Given the budget and time constraints we all work under and the range of expertise we're all expected to have (HTML, client-side scripting, the CGI, typography, image optimization, copywriting, usability engineering, user interface design, information architecture, salesmanship, customer service, etc. etc), it's unrealistic to expect developers to write to a third browser (which is what standards in effect are) that doesn't even exist.

As not only a web developer, but also a software developer for a rather long time - I'm very familiar with the "real world, clients, and practical constraints" argument. And, on the surface, it carries a lot of weight and "management appeal". But, I think that it needs a deeper examination to ensure that it doesn't miss some factor(s) which cost us dear down the road. Let me give you an example from the software world: if you have to write a program, there's basically two ways - as quickly as possible, or, spend some time on the requirements, design, and code quality issues. In the early days #2 wasn't popular with management - until software systems started getting more complex, bugs more frequent, and maintenance became a nightmare (e.g. Y2K). I'm not saying that history will repeat itself exactly the same for web developers, but, that there might be some useful parallels, and lessons to learn.

Improvements happened in the software world when developers started "front-loading" their development cycles, i.e. spending more time on the early phases. "Structured Analysis, Design and Programming" were invented and caught on - not only because management began to understand the downstream consequences of software that was written too quickly - but also because no-one wanted to be accused of "unstructured programming". So, if valid HTML is a Good Thing, perhaps we could coin a similar phrase that carries the connotation of "good vs. sloppy"..

Now, I claim that valid HTML is a Good Thing, and I imagine few professional developers would passionately disagree. But, I suspect that many developers feel that the "real world" doesn't allow time for the niceties of writing it - or, that it's just not possible, because the browsers don't support it. And my point is, yes, you will have to invest some up-front time, to study the W3C specs and to write valid code - but, you'll minimise the downstream problems, and find that it gets easier with practice (SP was hard at first, but after some experience, it became hard to not do it).

Let's recall the main reason for writing to the standards: pages should be viewable across the widest range of user agents, versions, and platforms. That includes not only the most popular GUI browsers and OSs but also text-to-speech synthesizers for the visually impaired; search engine spiders and other robots; tools, esp SGML-based ones; text-only browsers; devices other than PCs and Macs; and devices not yet available. For example, if you use UL or BlockQuote or other such tricks just to indent text then the page will break, sometime, for someone or something. "A conforming user agent for HTML 4.0 is one that observes the mandatory conditions ("must") set forth in this specification.." This implies, e.g. that certain popular tricks such as indenting text with itemless lists will break; since "All lists must contain one or more list elements.".

The W3C HTML specs are carefully designed to maximise accessibility, which most clients probably welcome - more potential customers! The legacy we're creating now, with non-compliant websites, could come back to haunt us if we're succesful in our efforts to get standards-supporting browsers.

Looking at the source code of many web sites, I noticed that many of the validation errors were easily avoidable - such as supplying the missing ALT attributes (NOT 'tags'!). If it became habit for people to include ALT (or to use generators that do) and do the other things that the specs require, then the extra time to "do it right" needn't be substantial, in most cases. I'd like to propose a methodology for web site development:-

• Write the first (possibly prototype) version in standard HTML.
• Validate it and all subsequent versions.
• If/when it meets requirements, attach the W3C HTML logo and link it to http://validator.w3.org/check/referer
• If full compliance isn't possible with your first design, look for other ways to code the page with valid HTML (e.g. workarounds; alternate design; etc).
• If you just can't do it, let the code become invalid, and write to the browser makers, this list, and/or me, with a description.

The most important step here is the first - it's harder to retrofit conformance than to start with it in the first place.

It's a 2-way street. You can't demand the browser makers observe the standards while you ignore them. What would Joe User think? And what will Jane think when she visits your site in Microscape 5 or 6 and it's broken because Netsoft decided to be stricter and less forgiving (as they've done before). It's easier to do it right than to do it over.

Before someone turns my argument around, squeezes out all the juice, and pushes it past the end-stop - I'm not saying that developers creating only compliant sites will force the browser makers to support the standards - directly. I *am* saying there might be some perceived hypocrisy in demanding standards while not observing them; *and* that it can be done more often and easily than many might realise.

Perhaps the worst thing that could happen is for the browser makers to suddenly "see the light" and fully and faithfully implement the standards, especially HTML 4.0 (e.g. by SGML parsing against the DTD). Sure, you'll get lots of nice new tags, and the old ones finally behaving right. But your spiffy sites will be spit out! Do you really want the standards, lock, stock, and barrel? If so, you may need to check your sites now. If not, state your wish more carefully..

BroWWWsers
HTML Standards Compliance - Why Bother ?
HTML Checkers