[VE][76] This message is preceded by nine useless messages

> Validating http://www.jtbusa.com/en/default.asp
> Error [76]: "element X undefined"

My problem is not with this error message; it seems to be adequate to the 
task.

Rather my problem is with the wasted effort and information with the 
preceding nine error messages that provide no actionable information because 
the problem lies with the element reported in this message. Of course 
there's no attribute X for an element that doesn't exist! Don't waste my 
time. It may even confuse other users who aren't so familiar with the 
validator or even the process of validation of code (compilers, etc.).

It even violates the general principle of cascading error messages, i.e., 
that the reported problem may be caused by a preceding error that confuses 
the error recovery system. In this instance it's impossible to fix a 
previously reported error because the error isn't reported until after the 
useless message.

While there will always be issues and arguments about proper error reporting 
and recovery, this one seems simple. Give me the actionable error only and 
ignore the others that we all know will automatically go away when the first 
is fixed. Skip to the next element and continue parsing.

R. W Crowl 

Re: [VE][76] This message is preceded by nine useless messages

On Tue, 01 Jul 2008 00:46:28 -0400
R.W. Crowl wrote:

> 
> > Validating http://www.jtbusa.com/en/default.asp
> > Error [76]: "element X undefined"
> 
> My problem is not with this error message; it seems to be adequate to
> the task.
> 
> Rather my problem is with the wasted effort and information with the 
> preceding nine error messages that provide no actionable information
> because the problem lies with the element reported in this message. Of
> course there's no attribute X for an element that doesn't exist! Don't
> waste my time.

The page refuses to validate at all (non UTF-8 characters). When i
changed the encoding to ISO-8859-1 there were 89 errors.

If you wish to discuss this further, you probably need to break it down
to a small test page with just the specific error involved, or fix all
the other errors on the page in question, then come back.

--

-- 
Michael

All shall be well, and all shall be well, and all manner of things shall
be well

Re: [VE][76] This message is preceded by nine useless messages

R.W. Crowl wrote:

> Skip to the next element and continue parsing.

It's an idea for XHTML and XML, but for HTML it's less
obvious what "next element" means after an unknown tag.

And for XHTML, if you have <dig> ... </div>, "next"
could be the end of file, because there is no </dig>.

 Frank

Re: major web sites

Brian Wilson wrote:

Rick Merrill <rickmerrill <at> comcast.net> wrote: -------------------------------------------------- Are there any "major' web sites that validate? If not, which ones have the fewest errors? I'm thinking of google.com yahoo.com altavista.com msn.com comcast.net What are the top 100 web sites? Do any of them validate?! -------------------------------------------------- Jens Meiert wrote:

(Not sure if this should be discussed on this list though.)

We're open to suggestions as to which list ought to be used

[not sure either, although it is an interesting data point to have in the argument about "why you should validate your documents"] One popularity measure (among many) is Alexa. It has some caveats, but in January I had the validator run through 487 of its Global Top 500 list. 32 of those URLs passed validation (6.57%). That is actually considerably higher than the average pass rate I found with the majority of the Open Directory Project URLs (DMoz). I have a complete list of those Alexa 500 that validated, but of the ones you mentioned, only msn.com passed validation.

How about a web page where you Post that complete list - with numbers of errors?  

HTH, -Brian Brian Wilson --------------------------"Those aren't Sex muffins! -Coach bloo <at> blooberry.com ---------------------Those aren't Love muffins! http://www.blooberry.com ---------------Those are just BLOOberry muffins!" Creator of Index DOT Html/Css: http://www.blooberry.com/indexdot/

-- http://www.batco.tv for Ch 10 info and schedule

Re: [VE][76] This message is preceded by nine useless messages

On 1-Jul-08, at 12:46 AM, R.W. Crowl wrote:

>
>> Validating http://www.jtbusa.com/en/default.asp
>> Error [76]: "element X undefined"
>
> My problem is not with this error message; it seems to be adequate  
> to the task.
>
> Rather my problem is with the wasted effort and information with the  
> preceding nine error messages that provide no actionable information  
> because the problem lies with the element reported in this message.  
> Of course there's no attribute X for an element that doesn't exist!  
> Don't waste my time.

This is indeed a usability issue, that comes from the underlying  
parser, opensp.

I would love an option to filter out unknown attribute errors for an  
unknown element. I'd make it a default, actually: if <foo> is unknown,  
then of course for <foo bar="quz" ...> bar will be an unknown  
attribute and quz an illegal attribute value - but it's useless info.

Openjade folks, is this something that has been considered before?  
Would it be hard to implement?

--

-- 
olivier

checklink: HTML 3.2 not recognised.

I would like to validate subsites containing pages in HTML 3.2.
The on-line service says it doesn't know about HTML 3.2.
"the Document Type (-//W3C//DTD HTML 3.2//EN) is not in the  
validator's catalog"
The text at the Documentation link does not say how to add new
(old) DTDs to the catalog.

--
"I don't want to discuss evidence." -- Richard Dawkins, in an
interview with Rupert Sheldrake.  (Fortean times 232, p55.)

Re: checklink: HTML 3.2 not recognised.

Le 2 juil. 2008 à 10:06, Richard A. O'Keefe a écrit :
> The on-line service says it doesn't know about HTML 3.2.
> "the Document Type (-//W3C//DTD HTML 3.2//EN) is not in the  
> validator's catalog"

Use <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

--

-- 
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

Re: [VE][76] This message is preceded by nine useless messages

http://home.earthlink.net/~silvermaplesoft/demos/embed.htmlPerhaps this 
trimmed down page will satisfy both Michael Adams and Frank Ellerman, who 
wrote> It's an idea for XHTML and XML, but for HTML it's less
> obvious what "next element" means after an unknown tag.

> And for XHTML, if you have <dig> ... </div>, "next"
> could be the end of file, because there is no </dig>.With the correct 
> </div> instead of the </dig> in this example, there are only ten errors --  
> the nine I have labeled as useless and lastly the real error of a 
> non-extanttag. The </dig> introduces three additional errors. Revalidating 
> as either 4.01 strict or transitional produces the expected errors about 
> XHTML issues but otherwise changes nothing.In all scenarios, parsing 
> appears to resume perfectly adequately with <div id="main">. And while 
> HTML can get away without closing some tags, the parser seems to have an 
> adequate idea of what "next element" means.As a former compiler writer 
> (USAF ADA contract), I am well aware of the difficulties of error 
> recovery. But I fail to understand how ignoring the attributes of an 
> element could possibly affect the parse stream. Either way it must find a 
> closing ">" to the element and then continue parsing. As it reads the 
> attributes it knows they are invalid precisely because it already knows 
> the element is invalid and all it's really doing is looking for that 
> bloody ">" so it can get on with the show. Does this clarify/simplify the 
> issue?R. W. Crowl 

Re: [VE][76] This message is preceded by nine useless messages

Somehow my mailer garbled my message. Here is what it should have looked
like:

http://home.earthlink.net/~silvermaplesoft/demos/embed.html
Perhaps this  trimmed down page will satisfy both Michael Adams and Frank
Ellerman, who wrote:

> It's an idea for XHTML and XML, but for HTML it's less
> obvious what "next element" means after an unknown tag.

> And for XHTML, if you have <dig> ... </div>, "next"
> could be the end of file, because there is no </dig>.

With the correct  </div> instead of the </dig> in this example, there are
only ten errors --  the nine I have labeled as useless and lastly the real
error of a  non-extant tag. The </dig> introduces three additional errors.
Revalidating as either 4.01 strict or transitional produces the expected
errors about XHTML issues but otherwise changes nothing.

In all scenarios, parsing appears to resume perfectly adequately with <div
id="main">. And while HTML can get away without closing some tags, the
parser seems to have an adequate idea of what "next element" means.

As a former compiler writer (USAF ADA contract), I am well aware of the
difficulties of error recovery. But I fail to understand how ignoring the
attributes of an element could possibly affect the parse stream. Either way
it must find a  closing ">" to the element and then continue parsing. As it
reads the attributes it knows they are invalid precisely because it already
knows the element is invalid and all it's really doing is looking for that
bloody ">" so it can get on with the show. Does this clarify/simplify the
issue?

R. W. Crowl 

Improper numeric equality test: "check" line 620

My Perl warns me of this:

 > check: Argument "text/html" isn't numeric in numeric eq (==) at 
/xxxx/validator-0.7.4/cgi-bin/check line 620, <fh00001default.html> line 1.

I've installed version 0.8.3 of the validator.