- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Tue, 1 May 2007 15:28:33 +0300 (EEST)
- To: Elliotte Harold <elharo@metalab.unc.edu>
- cc: Kati <kati.pe@comhem.se>, www-validator@w3.org
On Tue, 1 May 2007, Elliotte Harold wrote: > No. A validator can do quite a bit more than that. While a pure XML validator > might only check against a DTD, an *HTML* validator should check a document > for conformance to the HTML specification. To begin with, it cannot. Many normative parts of the HTML specification cannot be automatically checked (without artificial intelligence that goes far beyond the state of the art). Second, it would not be a validator any more. Call it a checker, or a lint, or an authoring tool, but don't call it a validator if it rejects valid documents or accepts invalid documents. > This specification(s) has some > constraints that are not and indeed cannot be expressed in a DTD. For > instance, there is the constraint that a elements are not nested. That's a constraint that can be expressed in a DTD, but that's irrelevant gere. > I am not sure if the META refresh directive is defined in the spec, but if it > is we should check it. No, we should not and we cannot. > If it's not, we might still want to check it if there is a decent spec for > that element and consensus on what should be there. The validator already > checks some accessibility issues that are not spelled out in the HTML spec. If it does that, it does not act as a validator. You can make a program warn about the use of red color (it could actually be quite useful), but this has nothing to do with a validator's job. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Tuesday, 1 May 2007 12:28:40 UTC