Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 520DC1337B59
	for <pgsql-docs-postgresql.org@mail.postgresql.org>;
	Wed,  3 Nov 2010 11:24:48 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 33329-01 for
	<pgsql-docs-postgresql.org@mail.postgresql.org>;
	Wed,  3 Nov 2010 14:24:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22])
	by mail.postgresql.org (Postfix) with SMTP id B84E21337B2F
	for <pgsql-docs@postgresql.org>; Wed,  3 Nov 2010 11:24:40 -0300 (ADT)
Received: (qmail invoked by alias); 03 Nov 2010 14:24:40 -0000
Received: from a88-115-218-165.elisa-laajakaista.fi (EHLO [10.0.0.101])
	[88.115.218.165]
	by mail.gmx.net (mp016) with SMTP; 03 Nov 2010 15:24:40 +0100
X-Authenticated: #495269
X-Provags-ID: V01U2FsdGVkX1/cYwd3py7cx0RSmnrunIIKLVEBJhh7nU5LGRT1U4
	zYUNaokawWMCEE
Subject: Re: Large SGML Cleanup
From: Peter Eisentraut <peter_e@gmx.net>
To: Josh Kupershmidt <schmiddy@gmail.com>
Cc: pgsql-docs@postgresql.org
In-Reply-To: <AANLkTi=1Sm9N3Khiued9UiMfdd_TKLimMiO9mCfHtL39@mail.gmail.com>
References: <AANLkTi=1Sm9N3Khiued9UiMfdd_TKLimMiO9mCfHtL39@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 03 Nov 2010 16:24:38 +0200
Message-ID: <1288794278.20884.2.camel@vanquo.pezone.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201011/10
X-Sequence-Number: 6208

On tis, 2010-11-02 at 22:56 -0400, Josh Kupershmidt wrote:
> This HTML fails validation, as one isn't supposed to be stuffing
> tables inside <p> nodes. The attached patch fixes all the instances of
> this I could find, by closing out <para> nodes before beginning lists
> and tables.

Um, this is like moving around the C code because the compiler generates
invalid assembly code.  Fix the compiler.

That said, we have the following in stylesheet.dsl:

;; Block elements are allowed in PARA in DocBook, but not in P in
;; HTML.  With %fix-para-wrappers% turned on, the stylesheets attempt
;; to avoid putting block elements in HTML P tags by outputting
;; additional end/begin P pairs around them.
(define %fix-para-wrappers% #t)

So evidently someone thought of this before and put something in to
prevent some/many/most cases.

In general, I think the more efficient way to address this overall
problem is to run the resulting HTML through tidy and be done with it.