Re: Toward Closure on HTML

"Daniel W. Connolly" <>
Date: Tue, 5 Apr 1994 17:40:46 --100
Message-id: <>
Precedence: bulk
From: "Daniel W. Connolly" <>
To: Multiple recipients of list <>
Subject: Re: Toward Closure on HTML 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2248
In message <199404051226.AA01079@RA.DEPT.CS.YALE.EDU>, Stan Letovsky writes:
>>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.

Point taken.

>>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.

I believe it is quite an issue. Would you care to construct an SGML
document demonstrating this style of markup? I think you'll find it's
non-trivial (but I think it is possible...)

>In other words, you would rather have a language that is convenient
>to parse than one that is convenient to use. Big mistake.

Well, I am trying to keep interactive processing in mind. Big mistake?
I dunno. There are much simpler syntactic idioms that are incorrectly
implemented in several browsers. This is the big mistake, if you
ask me.

> 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?

Well, I agree it's desirable. I just haven't been able to work out
a reasonable representation in SGML. If you've got one handy, let's
see it.

> 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

Is it necessary to vent like this to the whole list? I'd prefer you
sent your personal remarks in private email.