Re: Standardizing new HTML features

Dave_Raggett ([email protected])
Wed, 28 Apr 93 11:52:52 BST


Tony Johnson writes:

> Excellent! One area I would like to see clearly documented is what types of
> nesting of tags is legal, I have not found it clearly documented in the
> existing HTML documentation (of course maybe I didn't follow the right link).

> For example, which of the following are legal/supported/encouraged HTML??

> <a href=x>The <h1>Link</h1></a>
> <a href=x>The <b>link</b></a>
> <b><i><e>Weird</e></i></b> etc. etc. etc....

The current DTD specifies that anchor text is PCDATA. This perhaps too strong
as it rules out ANY tags occurring between <A> and the </A>. The same is true
for the tags: <EM>, <TT>, <STRONG>, <B>, <I>, <U>, <CODE>, <SAMP>, <KBD>,
<VAR>, <DFN> and <CITE>.

The DTD also gives limitations on which tags can occur within lists - namely
the preceding tags, together with <LI> and <P>, but *no* nested lists.

I have a feeling that most people find the SGML DTD rather hard to follow
in detail. Goldfarb's account of SGML almost seems to go out of its way
to make life difficult for the newcomer. Perhaps we need to supplement the
HTML DTD with a more accessible BNF style description.

> Of course one answer is that browsers should do their best with whatever they
> get....but I think in the interest of portability (and of something that works
> fine with ine browser working equally well with another one) it would be better
> to document what things are required to be supported.

An easy to understand, yet precise description of the core HTML is needed.
I feel we would also benefit from some guidelines for dealing with bad HTML,
and pointers to experimental extensions.

> It would also be useful for browsers to have a -noextentensions flag
> (or some moral equivalent) under which they flag anything other than the
> strictly supported constructs to aid people in writing portable HTML.

My first browser did this - but I got fed up with all the error messages!
Perhaps the browser should just report the document as not conforming
to the core spec and leave it to a separate program to generate a full report.

Regards,

Dave Raggett