RE: HTML 3.2 PR: Please add CLASS attribute!

>In this case it is, the DTD describes TITLE... its illegal, even in
>FOO, its the idea that I even used FOO I don't want to be "errored" at
>...  Warned maybe, but every validation service I have used desires to
>call them "ERROR!"

Most validation services are designed to determine that a given document conforms to
a given document type definition -- if an element that is not defined by the DTD is used
in the document being validated, the document contains an error (it does not conform).

If you are designing something that parses HTML you should realize that there are a few
levels to Doing It Right.

First level is being able to correctly parse the markup in the document (regardless of the
elements being used).    This means being able to identify markup and entity delimiters
properly (this can be quite a bit of work, but worth the effort if it is done well).

Second level is knowing about the elements used in HTML and how they relate to each
other.  This means being able to handle SGML constructs like ommissable elements --
ie. knowing that <P> is not allowed inside <P> allows you to determine the end of the
aragraph without specifying </P>.

Third level is knowing which attributes are associated with what elements.  This means
being able to supply default values for attributes and knowing which attributes to allow
and which to ignore.

For something like a browser, which should be permissive in what it accepts, the parser should definitely be able to process the document at the first level, and will probably need some of the
second.  For an authoring tool, which should create valid documents, first, second, and some
of third is probably appropriate.  For something like a validator, which determines if a document
is correct, all levels are needed.

The document type definition contains all the information needed about elements and their
attributes.  It is up to you to determine how much of that information you will use when parsing
a document.


Ben Fuller

Macromedia Backstage
Designer Engineering Team
(resident parsing dude)

Received on Friday, 22 November 1996 20:46:40 UTC