Re: Questions on elements/Diffs from old HTML DTD.

Daniel W. Connolly (
Wed, 27 Jul 1994 15:01:54 -0500

Message-Id: <>
To: Earl Hood <>
Subject: Re: Questions on elements/Diffs from old HTML DTD. 
In-Reply-To: Your message of "Wed, 27 Jul 1994 14:09:25 CDT."
Date: Wed, 27 Jul 1994 15:01:54 -0500
From: "Daniel W. Connolly" <>

In message <>, Earl Hood writes:
>What is the reasoning for allowing header elements inside a BLOCKQUOTE

There's no compelling technical argument, but the result of my musings
on BLOCKQUOTE is that it should have the same content model as BODY.
That way, anything somebody can put in an HTML BODY, you can quote.
It seems to make sense to me. Do you have a specific objection?

Note that ADDRESS is allowed in the content of BODY or BLOCKQUOTE, but
not anywhere else. (1) this agrees with current practice in the
examples that I found, and (2) it makes sense to me: you can "sign" an
HTML document by putting an ADDRESS in the BODY, and you can attribute
excerpts somebody else by putting the excerpt in a BLOCKQUOTE and
putting the attribution in an ADDRESS inside that BLOCKQUOTE.

>I've also noticed that the COMPACT attribute for UL/OL elements are
>still gone from earlier version of HTML.  Is it a conscience decision
>to remove the attribute?  The DL element has it, so I find it odd that
>the other list types should not.

****** When you submit comments, please cite the address/version/date/name
****** of the document you're commenting on.

I intended to fix this recently. I did fix it in my copy of the DTD,
and the change propogated to the current online version of the DTD at:
but it's possible that you're looking at some version of the DTD where
this is missing:

 <!ELEMENT (%list) - -  (LI)+>
 <!ATTLIST (%list)

>It would be nice that there existed some sort of "diff" between the
>newer versions of the HTML DTD from the older versions.

I have all the versions in RCS ,v files. I can generate any sorts
of diffs you like. I don't think you'll find them very readable, though
I can see your point.

Have you looked at:

>  Here is the
>list I have from the changes from the old HTML DTD of Jul 1 93, and the
>latest HTML DTD from

Ah! That copy is out of date. I'll update it ahorita...

The document has gone through some major revision, including
conversion to FrameMaker and back to HTML. As a result, things are
somewhat unstable at the moment. The new HTML stuff isn't in the
html-spec directory. The URL to use as a reference is:

if you follow the links from there, you should always get up-to-date

>New elements/attributes:                                              
>    <br>
>    <dl compact>
>    <form>
>    <form action>
>    <form enctype>
>    <form method>
>    <img ismap>
>    <input>
>    <input align>
>    <input checked>
>    <input maxlength>
>    <input name>
>    <input size>
>    <input src>
>    <input type>
>    <input value>
>    <option>
>    <option selected>
>    <option value>
>    <select>
>    <select multiple>
>    <select name>
>    <select size>
>    <textarea>
>    <textarea cols>
>    <textarea name>
>    <textarea rows>

Yup, that stuff is all new since the HTML 1.3 draft. Neat list too.
Maybe I should grab these perl ditties and use them myself! (Of course
I've got my own perl ditties, but you seem to have a lot more time to
spend enhancing them than I do.)

>Old elements/attributes:                                                  
>    <dfn>
>    <key>
>    <u>

These aren't supported by Mosaic, so it went into "Proposed" status.
The goal is that if a document parses, that implies that it works on
the majority of widely deployed browsers. (Note that the converse is
not nearly as high on the list of goals.) We split the features into
levels to achieve this: if a doc parses by the level 0 DTD, it'll work
everywhere. If it parses by the level 1 DTD, it'll work on level 1
implementations (Mac Mosaic without forms, e.g.). If it parses by the
level 2 DTD, it'll work on level 2 implementations (XMosaic, w3.el,

>    <link name>

Good catch. I never gave this much thought, though I'm not sad to see
it go. I do have a test suite -- on the order of 100 documents -- that
I run every time I make a change to the DTD. In those 100 documents,
nobody used <link name>. More test documents are always welcome.

>    <dir compact>
>    <menu compact>
>    <ol compact>
>    <ul compact>

These are back in by now.

>A "diff" document will be good for users of HTML to easily determine
>what elements/attributes are obsolete.  Either that, or update the
>"Obsolete" section of the html spec that _completely_ lists all changes
>from the older version(s) of the DTD.

Are you volunteering to write this "diff" document? I have nearly run
out of cycles for editing the HTML document. I am still the editor
through the publication as an RFC, but I am delegating everything
now. Other folks are doing the remaining edits (and producing new
postscript and text versions from HTML), and I am coordinating them.

A "Changes since 1.3" section would be great. If you're willing to
contribute it, I'll make every effort to see that it gets in.

>Probably a better distinction is "obsolete" vs "removed".  Some elements
>are labeled obsolete in the html spec, but are still defined in the
>DTD.  While some stuff has been completely removed from the DTD.

Elements like XMP and LISTING are obsolete because their original
specification is not expressible in SGML, and hence they are used and
implemented inconsistently. They're still in the DTD for -- well, no
good reason, except that I generate some reference documentation (and
some code!) from the DTD, and for those purposes, I need them in

Nothing should really get "removed," though in some cases, if nobody
is using it and it doesn't make any sense in the first place, it might
get lost in the shuffle like <link name>. In other cases like <dfn>,
it just never got widely depoyed, so we choose not to call it
standard in this revision. Perhaps a 2.1 document will re-instate
<dfn> and such. Perhaps not.

>P.S.  How does one subscribe to www-html?  Is it an exclusive club, or
>am I too dense to find the URL that explains how to subscribe? :)

I dunno, but the first thing I would try is sending mail to the conventional
administrative address for any mailing list:

>  I'd
>like to keep up-to-date as possible on HTML since I have programs that
>deal with it.

Then you should be aware of the newly formed HTML Working Group of
the IETF, unanimously approved last night at the Toronto IETF meeting.
Stay tuned for details.