Re: Fate of <P> [Was: Toward Closure on HTML]

"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 7 Apr 1994 21:03:54 --100
Message-id: <9404071850.AA21181@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: Fate of <P> [Was: Toward Closure on HTML] 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0
Content-Length: 3447

In message <9404071130.aa02239@paris.ics.uci.edu>, "Roy T. Fielding" writes:
>Dan Connolly writes:
>
>> In message <9404070808.AA24233@dragget.hpl.hp.com>, Dave Raggett writes:
>>>        
>>>SGML allows you to omit end tags when specified by the document type
>>>definition, as parsers can easily infer the end of the element. In this
>>>case the next <P> tag implies the end of the previous paragraph.
>> 
>> I suggest that even though this is doable, it is not consistent with
>> current practice -- and I'm not talking about technical matters here.
>> Much of the HTML documentation (NCSA's primer, CERN doc, etc.) says
>> that <P> is a paragraph separator, not a paragraph container. I think
>> this is the way 95% of the HTML authors see it in their heads.
>
>While this is true today, I don't think that it makes any difference
>given the way Dave has defined the <P> element in HTML+.  All of the
>current primers could be changed within a single day if people on this
>list get it in their heads to do so.  Given the rate of change on the Web 
>and the current lack of established authoring tools for HTML, I think
>95% of HTML authors would be using <P> as a container within 3 months.
>Furthermore, a simple script could be written to reformat most existing
>HTML documents (a generic parser for SGML is unnecessary and less useful
>because it cannot intuit the intentions behind the elements).  Naturally,
>some of the more "artistic" documents would require hand-editing, but 
>they are rarely conforming to begin with.  I'll write the script myself
>once I get done with my stack of current scripts-to-write (at least a
>month's worth already).  Hopefully, several other people will have already
>done so by then.

This is a reasonable argument. In fact, I agree completely.
I'm sure I could augment html-mode.el to do this while it's putting
quotes around attribute values, for example.

The question is: which way is the momentum out there? Will folks
really clean up their stuff? How long will it be before I can
use an SGML parser and a P container with reasonable results
on real stuff out there?

The fact remains that stuff parses as-is with the empty P element.
So if anybody's interested in an immediate informational RFC, that's
the way it's got to be.

Whether there's anything between html.dtd v 1.7.2.4 and HTML+ remains
to be seen.

>> I suggest HTML+ use a new name for this paragraph container element,
>> say PP. When folks mean paragraph separator, they can write <P>. When
>> they mean container, they can write <PP>.
>
>Sorry, but I think that's a terrible idea.  It would give us two syntactic
>forms for a single semantic structure -- that of a paragraph -- where only
>one form is necessary.

Again, I'll assert that <P> is a separator and <PP> is a container. Two
different things.

>  In addition, a <PP> element would be ignored by ALL
>existing clients whereas using <P> as a container is already accepted by
>most.

So write
	<PP>Here's my para<p></pp>

and it'll work everywhere. When <pp> is well established, just
s/<p>//g and be done with it. I guarantee that's a lot easier and
more reliable than the script that changes <p> from a separator
to a container.

Dan

Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html