Re: Ignoring empty paragraphs

On Mon, 10 Apr 2000, Braden N. McDaniel wrote:
> On Mon, 10 Apr 2000, Ian Graham wrote:
> 
> > On Sun, 9 Apr 2000, Braden N. McDaniel wrote:
> > > On Sun, 9 Apr 2000, Jan Roland Eriksson wrote:
> > > 
> > > > On Tue, 4 Apr 2000 03:09:26 -0400 (EDT), "Braden N. McDaniel"
> > > > <braden@endoframe.com> wrote:
> > > > 
> > > > >On Tue, 4 Apr 2000, Jan Roland Eriksson wrote:
> > > > >> On Mon, 3 Apr 2000 19:53:18 -0400 (EDT), "L. David Baron"
> > > > >> <dbaron@fas.harvard.edu> wrote:
> > > > >> > 1) An empty P element should be ignored at the parsing stage, and
> > > > >> >    therefore should not appear in the DOM and should not be affected
> > > > >> >    by style sheets.
> > > > >> 
> > > > >> This is the correct interpretation.
> > > > 
> > > > [...]
> > [ .... ] 
> > I think the wording in the HTML spec should not be trusted -- it is simply
> > too vague.  The intention, if I remember correctly, was that consecutive
> > empty <p>'s would, when rendered, collapse to the same vertical spacing of
> > a single <p>, or to nothing at all.
> 
> If you remember from *what*? What can we consult, if indeed the wording in
> the HTML spec is not to be trusted?

I am afraid I don't know where this is found ... I've poked around a
bit in the mail archives, and the only messages I could find that
seemed relevant were:

http://lists.w3.org/Archives/Public/www-html/1995Nov/0077.html
http://lists.w3.org/Archives/Public/www-html/1997Jul/0306.html
http://lists.w3.org/Archives/Public/www-html-editor/1998AprJun/0140.html
http://lists.w3.org/Archives/Public/www-html-editor/1998AprJun/0142.html
http://lists.w3.org/Archives/Public/www-html/1997Jul/0240.html

They don't help much, although the latter one quotes an earlier HTML 4
draft that had wording such as:

  "Empty P elements are bad form and should be ignored by the renderer"

> > The problem is that the HTML spec
> > doesn't say how this could be done, since it is a markup spec, and not a
> > formatting/parsing specification.
> >
> > [ ... ] 
> > and then later use script code to appropriately fill the <p>'s. Obviously
> > the code will fail if the parser/processor has decided to prune these
> > empty but needed elements from the tree.
> 
> The HTML spec doesn't know anything about the DOM, really. I only
> interpret it as referring to P elements described in static documents.

Well, yes, but the idea of removing empty <p>'s from the tree (which 
started this thread) kinda impacts on parsing and the DOM....

> > Moreover, with XML this would simply be illegal -- an XML parser can
> > _never_ modify the incoming data, as Tantek pointed out.
> 
> Irrelevant. HTML is not XML.
>
> > All it can do is
> > tell the XML application whether or not white space is significant in
> > certain contexts. It does not make sense at this point to let HTML
> > applications do things that XHTML ones cannot.
> 
> They already can.

Well, yes, but I figure it's a Bad Thing to make the processors even more
divergent at this point.  Right now the XML specs say that XML parsers
can't chuck empty elements out, while part of the argument here is that
maybe HTML processors 'should' do so. I am simply arguing that it makes no
sense to give HTML processors, at this late stage, a 'new' ability that is
incompatible with the technology we want to migrate towards.
  
> [.... ] 

> > Regardless, it would seem useful to change the wording of the HTML
> > specification (Section 9.3.1) to more carefully say what this "really"
> > means. Something like:
> > 
> >   We discourage authors from using empty P elements. User agents should
> >   not render empty P elements. However, style sheet instructions should be
> >   able to control whether or not empty P (or other) elements are included 
> >   in the rendering process.
> > 
> > might be better. 
> 
> Decisive evidence that such language does, in fact, represent the intended
> meaning of the spec on this point would probably settle this.

Well, yes, that's true.  Memory, after all, is a treacherous thing....

Ian
Ian

Received on Monday, 10 April 2000 16:49:23 UTC