W3C home > Mailing lists > Public > www-validator@w3.org > September 2001

Why Validate?

From: Nick Kew <nick@webthing.com>
Date: Mon, 24 Sep 2001 09:25:32 +0100 (BST)
To: www-validator@w3.org
Message-ID: <Pine.BSF.4.21.0109240824050.1482-100000@fenris.webthing.com>

I've just drafted an answer to this.  Review please.

I'd be happy for this to become the basis for a "why validate" page
at validator.w3.org.

(Liam - please feel free to kick me if I don't get around to reviewing
how this might fit with htmlhelp's existing "reasons to validate").

*** Why Validate?

Well, firstly there is the very practical issue that non-valid
pages are (by definition) relying on error-correction by a
browser.  This error correction can and does vary radically
across different browsers and versions, so that many authors
who unwittingly relied on the quirks of Netscape 1.1 suddenly
found their pages appeared totally blank in Netscape 2.0.
Whilst Internet Explorer initially set out to be bug-compatible
with Netscape, it too has moved towards standards compliance in
later releases.  Other browsers of course differ further.

There are also three specific questions we should deal with here:

(1) The novice (or non-technical website owner) question:
    "my site looks right and works fine - isn't that enough?"

The answer to this one is that markup languages are no more than
data formats.  So a website doesn't look like anything at all!
It only takes on a visual appearance when it is presented by
your browser.

In practice, different browsers can and do display the same page
very differently.  This is deliberate, and doesn't imply any kind
of browser bug.  A term sometimes used for this is WYSINWOG -
What You See Is Not What Others Get (unless by coincidence).
It is indeed one of the principal strengths of the web, that
(for example) a visually impaired user can select very large print
or text-to-speech without a publisher having to go to the
trouble and expense of preparing a separate edition.

It is perhaps unfortunate that the best-known browsers - Netscape
Navigator and MS Internet Explorer on Windows - are visually very
similar indeed in their presentation of many documents, differing
only in trivial details like margins and spacings.  The "same" browser
on a Mac or Unix/Linux display will often look far more different.

  (2) The perceptive observation "lots of websites out there
      don't validate - including household-name companies."

Do remember: household-name companies expect people to visit *because of*
the name and *in spite of* dreadful websites.  Can you afford that luxury?

Even if you can, do you want to risk being on the wrong side of a lawsuit
if your site proves inaccessible to - for instance - a disabled person who
cannot use a 'conventional' browser?  Accessibility is the law in this
and other countries.  Whilst validation doesn't guarantee accessibility
(there is no complete substitute for common sense), it is an important
component of exercising "due diligence".  It is now just over a year
since a court first awarded damages to a blind user against the owners
of a website he found inaccessible (Maguire vs SOCOG, August 2000).

  (3) The strawman argument "validation means boring websites, and
      stifles creativity".

This is simply head-in-the-sand ignorance (indeed, it lies at the heart of
many of the most spectacular dot-com failures).  Validation is fully
compatible with a wide range of dynamic pages, multimedia presentations,
scripting and active content, etc.  It is part of the difference between
doing it right and doing it wrong in a dynamic multimedia presentation,
just as much as in a purely textual site.

It is perfectly reasonable for authors to express their creativity on
the Web, though it is clearly more approriate to (say) a recreational
site than to an informational one.  But authors should bear in mind that
in any artistic field, you need to start with a thorough understanding
of the rules before breaking them.  Otherwise you just look foolish.

Nick Kew

Site Valet - the essential service for anyone with a website.
Received on Monday, 24 September 2001 04:36:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:58:24 UTC