Re: Toward Closure on HTML

• Mail folder: WWW Talk Apr 94-present
• Next message: Vinay Kumar: "Re: Toward Closure on HTML"
• Previous message: Dave Raggett: "Re: Toward Closure on HTML "
• Maybe in reply to: Dave Raggett: "Re: Toward Closure on HTML "
• Reply: Daniel W. Connolly: "Re: Toward Closure on HTML "

Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 17:40:46 --100
Message-id: <9404051529.AA16896@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
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: 2248

In message <199404051226.AA01079@RA.DEPT.CS.YALE.EDU>, Stan Letovsky writes:
>>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.

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

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

Dan