Re: behaviour of validator with script and noscript

Hi Maria, on Tue, 12 Oct 2004 09:40:31 +1100 you wrote:

> Hi all,
> I evaluated our new home page for accessibility,
> http://www.utas.edu.au/, and referred the issues found, including
> invalid HTML (from http://validator.w3.org/) to the designer. This
> person responded as follows: Most of the "invalid" code is either an
> overly strict interpretation irrelevant to most web browsers 

It's hard how to know to respond to such deliberate contortion of the
truth such as your "designer" is inflicting on you.

Firstly, make sure you understand the tool and the purpose of what you're
doing. What you're dealing with is a validator, which gives you a
consistent black-or-white answer as to whether a document is valid or not.
"Valid" in this context has a specific meaning, and means that a document
is conformant with the document type it claims to be (HTML 4.01
Transitional in your case). Given that the validator is working from *the
official standard* (or, at least, the official machine-readable subset
definition of it), for someone to claim it's "overly strict" is, frankly,
absurd and utterly meaningless. Either it's valid (according to the
standard), or it's not. I'm not sure what your "designer" wants - perhaps
for the validator to say "Good try - not far off. Sort-of valid, good
enough"?! It sounds like in their opinion they think the standard is
overly restrictive - that's fair enough as an opinion, but that ignores
the reality of the situation (that, right now, the standard they are using
says a certain thing) and begs the questions:

a) have they got involved in working groups developing future versions of
the standard, got involved and discussed their concerns, and

b) why is it that they are such a unique case that what's been a standard
for many years and which many other people find adequate for their needs
just isn't good enough for them? Is what they're doing so amazingly
technologically special and elite that the standard just isn't good enough
for them? (The answer, by the way, is no, but even if it were "yes" you'd
have to carefully weigh up the advantages and disadvantages of going off
doing your own thing)

I think you need to define your goals clearly. Are you designing for
specific web browsers (perhaps what your designer considers "most" people
use) or aiming for universal accessibility? If the former, then using a
validator is mostly pointless, because you're using a tool that tells you
something you're not actually interested in. If the latter, then the
situation is black or white as far as document validity is concerned:
either it's valid, or it's not. The validator will distinguish clearly
whether it is or is not valid. The page in question is not valid. (Note
that validity is only one helpful step along the way to accessibility; it
does not guarantee it in itself. But you probably knew that anyway).

Now, from a strictly pragmatic point of view it's true that *some* errors
made by your designer (such as use of non-existent attributes) are of
relatively minor importance (and could reasonably be called "low
priority"), since as long as the document is otherwise well-formed,
unknown attributes will generally be ignored by user agents and so as long
as the document doesn't *rely* on them then problems will probably be
minimal. However, the same can't be said of all the errors - some of which
could conceivably lead to widely-differing interpretations of the page. In
general with an invalid document, all bets are off as to how a page
renders in a given user agent - you're relying on undefined error
correction. However, I don't even see the point in spending the mental
energy considering this, because to be honest, there is no need for the
page to be invalid - the problems could be easily fixed in 5 minutes
without compromising in any way your designer's (clearly unique)
requirements.

> failure of the tool to cope with a valid use of noscript tags.

This is, frankly, nonsense. What use would a *validator* be if it called
valid code invalid? I can see what your designer's trying to achieve but
we get back again to the point that their definition of "valid" is
subjective, but you are using an objective validator with a strict
definition of "valid". In this case it is *not* a "valid" use (where
"valid" means "conforming with the claimed document type") of noscript
tags. The code is invalid, plain and simple. This is a poor excuse,
particularly since you could achieve an identical result *and* have valid
code.

> " This person also claimed the same for their invalid CSS.
> Is this true?

No, you just have a lazy "designer". Again, being pragmatic, I doubt the
CSS markup that your designer has invented is going to do much harm in
"most" user agents - it will just be ignored. But in that case, why keep
it there?! It's simply not necessary. In any case, you can achieve the
same effect with valid CSS.


What mystifies me most of all is why your designer is making such a fuss.
There is no need for the errors they have introduced - the page could work
just as well whilst being 100% valid. More to the point, they could have
fixed the errors in less time than it's taken for you to ask the question
or for me to write this e-mail. So irrelevant of whether they think it's
important or not, or whether they think they know the HTML standards
better than the validator (they don't), why didn't they just *fix* them,
instead of arguing the toss?

Don't get me wrong; invalid code can be introduced for any number of
reasons. Even the validator site has been known to have invalid code from
time to time. And naturally, priorities for fixing things vary - the world
is clearly not going to fall in overnight if your designer doesn't fix an
odd broken attribute. But the point is that when it takes longer to have
an argument about whether the particular errors on a page are "important"
or not than it would just to fix them, or when the person in question
starts talking self-contradictory nonsense like "the validator is overly
strict", I'd venture to suggest that you've got to ask yourself: "why are
we even having this discussion?".


Tim

Received on Tuesday, 12 October 2004 00:09:50 UTC