Re: Toward Closure on HTML
Stan Letovsky <letovsky-stan@CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 14:28:48 --100
Message-id: <199404051226.AA01079@RA.DEPT.CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: letovsky-stan@CS.YALE.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Stan Letovsky <letovsky-stan@CS.YALE.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Toward Closure on HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2593
Subject: Toward Closure on HTML
From: "Daniel W. Connolly" <connolly@hal.com>
Date: Tue, 05 Apr 94 02:10:24
To: Multiple recipients of list <www-talk@www0.cern.ch>
---------
..
>NEWLINES, PARAGRAPH BREAKS, AND <P>
>
>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.
</flame>
-Stan