Error misinterpratations and limitations

When validating someone's page who used the
proprietary <embed> tag and also had no doctype. The
validator gave this message:


Line 59, column 313: element "EMBED" undefined
...x.cgi?P1_Prod_Version=ShockwaveFlash"></EMBED>

You have used the element named above in your
document, but the document type you are using does not
define an element of that name. This error is often
caused by incorrect use of the "Strict" document type
with a document that uses frames (e.g. you must use
the "Frameset" document type to get the "<frameset>"
element), or by using vendor proprietary extensions
such as "<spacer>" or "<marquee>" (this is usually
fixed by using CSS to achieve the desired effect
instead).


The addional info such as "may be caused by" is very
useful, but sometimes it's not necessary. What I mean
by "Sometimes" is that the error can be displayed in
more than one event, which can be interpretted from
more than one type of error. The problem is that
errors such as #76 (this one) will be displayed if
someone uses an invalid tag or attribute. Invalid can
mean 2 things:

1. The tag or attribute is proprietary and has never
existed in the standards in any DTD ever in existance.

2. The tag or attribute is invalid _in the specific
DTD_ (or some, but not all DTDs).

Both of these are valid and common problems that share
this same error. I think the errors should be
partitioned better, along with a more thorough
validation check to see if the tag / attributes are
truly invalid or not. I know each error number is
documented and changing the names of the error
database  wouldn't be an easy solution. That would be
like renaming every HTML tag. It wouldn't be backwards
compatible for reference. XHTML is being better
organized by modules. I propose that the errors should
be organized in a similar way. For example, we could
have a range of error numbers dealing with syntax
problems, another range for DTD-specific errors, etc.
This way, we can expand on the already existing error
messages rather than try to bloat an overused error
with several cases of different possible errors. And
this would also clean up the priorities of procedure
the validator should follow as well as the readability
of the error number. With this, someone could say for
example "I received an error 2.4" and it wouldn't be
an unsorted mystery as to what that was. The numbering
scheme can even be connected in some way with the
sections in the HTML specification documentation (such
as section 9 in the HTML 4.01 spec's table of content
is all about text and 11 is all about tables).

It would be hard to accomplish but it's possible.
There isn't much else we can do to the few shallow
existing errors.


~XFox Prower


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/

Received on Wednesday, 2 June 2004 22:11:37 UTC