Re: Toward Closure on HTML

Stan Letovsky (letovsky-stan@CS.YALE.EDU)
Tue, 05 Apr 94 08:26:26 -0400

Subject: Toward Closure on HTML
From: "Daniel W. Connolly" <>
Date: Tue, 05 Apr 94 02:10:24
To: Multiple recipients of list <>
>Folks have asked why the <p> tag is necessary at all -- why can't we just
>use a blank line like troff and TeX?
>First, it's too late to do that: there are too many documents with blank
>lines that don't indicate a paragraph break.

HTML is not yet at the point where it should be regarded
as cast in stone. An incompatible would-be successor HTML+
is already on the horizon. Now is the time to consider
such changes.

>Second, not everybody wants it that way: I'd like to be free to stick blank
>lines in lists and such without introducing paragram breaks.

This is a non-issue. LaTeX has a perfectly reasonable approach to
ignoring extra paragraph breaks in list contexts; use that.

>Third, the mechanism for expressing this in SGML, SHORTREF, introduces
>significant complexity to parsing HTML. It opens up a canof worms including
><em/foo/ and other tricky parsing idioms.
>But I would like to introduce one change to the way P elements work: I'd
>like to make the P element a paragraph container rather than a paragraph
>separator. The only required change is to put a <p> tag at the beginning of
>every paragraph -- we can use the OMITTAG feature to make </p> tags
>implicit. It makes for a much cleaner DTD in many ways, and it just makes
>more sense.

In other words, you would rather have a language that is convenient
to parse than one that is convenient to use. Big mistake. The
<p> ... </p> construct is a big step in the wrong direction: it makes
a simple construct like a paragraph, which was already well handled
by a text-editor, into something onerous. It is not clear that your
ommittag fix is backward compatible, since it suggests <p>'s at the
front of paragraphs instead of at the back; if an incompatible
change like this is possible, then why not double-\n? But the
bigger issue is that you are ignoring user preferences in favor
of anal-retentive coder preferences: no one but a parser-writer
would view <p> ... </p> as an elegant way to say "this is a
paragraph. Similarly for <li>, etc. If we have a system that works
with one level of syntactic nuisance, what possible motive
could there be for making a change whose sole effect is to increase
the level of syntactic nuisance? You are only creating a niche for
someone to fill with a user-oriented HTML-Lite, just as LaTeX
replaced the essentially unusable TeX.