2589 - Empty <P> elements not ignored as required by HTML4 spec

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Hixie (not reading bugmail)]

The HTML 4.0 specification states, at
   http://www.w3.org/TR/REC-html40/struct/text.html#h-9.3.1
...that empty <P> elements should be ignored.

To be precise, it says:

   User agents should ignore empty P elements.

Mozilla does not. See the test case quoted above.

Note. This is not a parsing error, as if the DOM later adds content to an
empty P element, the element should be drawn.

In other words, the <P> element in HTML is a special case where *if it is
empty*, it should not be rendered. If a (NGLayout internal) pseudo-class
such :empty" was defined, and it applied to all empty elements, then the
rule above could be described as follows:

   P:empty { display: none ! important; }

However, this rule should have infinite specificity, and the :empty pseudo
should not be accessible to anything outside the browser.

Comment 1

[leger]

Setting all current Open/Normal to M4.

Comment 2

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 3

[kipp]

We now pass the collapse test for block elements and P elements.

Comment 4

[Hixie (not reading bugmail)]

Wow. Impressive. One more step towards world domination...

Comment 5

[Hixie (not reading bugmail)]

One minor problem with the way you have implemented this. See test two of:
  http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/emptyinline.html
Basically, an empty <P> between two anonymous inlines causes a line break,
although if it was actually ignored, then the two anonmyous inlines would
flow into each other, as they do in test four of that page.

Once the above test is passed, make sure that the following still works ok:
  http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/collapse.html

[ccing David as he has been involved with this bug]

Comment 6

[kipp]

This bug is going to be next-to-impossible to fix...Don't hold your breath.

Comment 7

[kipp]

The HTML4 spec is, shall we say, inconsistent with the >10^9 web pages already
in existence. Their intention is to make things like this:

<P>white-space...<P>white-space...<P>Hello World!

Render such that the two paragraphs containing nothing but whitespace disappear.
This is "accepted" practice and (I strongly believe) what the "spec" authors had
in mind. The initial <P> will provide a margin for collapsing purposes and
provide a line-break if preceeded by inline content. The first P's bottom margin
and the second P's top margin will collapse; the second P's top and bottom
margins will collapse; the resulting single margin value will collapse with the
3rd P's top margin resulting in exactly one margin. All is well.

Comment 8

[Hixie (not reading bugmail)]

The above would also work if the first two dissapear altogether,
since the last <P> is a block box and thus causes a "line break" before it.

The bug I reported is that the following:

   <DIV>
     <SPAN> Some text </SPAN>
     <P></P>
     <SPAN> Some more text </SPAN>
   </DIV>

...should be treated like this:

   <DIV>
     <SPAN> Some text </SPAN>
     <SPAN> Some more text </SPAN>
   </DIV>

...because the <P> is *ignored* according to the spec. NGLayout currently
treats the second SPAN as a block level element, *if* (and only if) the P is
declared as being a block level element also.


The following:

   Text
   <P>
   <P>
   <P>
   <P> Text

...will become this during parsing:

   <P>Text</P>
   <P></P>
   <P></P>
   <P></P>
   <P> Text</P>

...which should be treated like this:

   <P>Text</P>
   <P> Text</P>

...as it in fact does (we all agree on this).

Please show me a document fragment that would break if you ignored
empty P elements when they intermix inline text with empty Ps.

Note that my behaviour is exactly what automatically happens when
the "ignore empty Ps" behaviour is coded as:

   P:-moz-empty { display: none ! -moz-always; }

Also note that the creation of anonymous block and inline boxes should
occur *after* the removal of empty Ps (this is consistent with the CSS
rule I suggest above).

Comment 9

[kipp]

Try these two tests in IE and NAV; You can try opera too if you care...

Test #1 (your test):

   <DIV>
     <SPAN> Some text </SPAN>
     <P></P>
     <SPAN> Some more text </SPAN>
   </DIV>

Test #2:

    This <B>Bold venture</B>, we hope
    <P></P>
    goes beyond our meer mortal wills.

In both cases a line-break will occur where the so called "disappearing P" is in
the content. This is expected web behavior and I claim that the HTML4 spec is
living in fantasy land to claim otherwise (its also living in fantasy land in
the ways that it is contrary to the html3.2 spec)

Hence, I'm WONTFIX'ing the bug.

Please kindly stop re-opening it. Thanks.

Comment 10

[kipp]

I'm re-opening because recent changes broke the P collapsing code :-(

Comment 11

[kipp]

Fixed. The page now renders correctly; note that the "should not collapse
section" doesn't match what the author intended, but note that the author agrees
that the results are not agreed upon...

Comment 12

[Hixie (not reading bugmail)]

Looks fine from here, 1999-03-31 build.

Comment 13

[Hixie (not reading bugmail)]

For the record, it has now been decided that the spec was out of line when 
saying that empty <p> elements should be "ignored" -- or at least, they should
not so much be ignored as "the default UA stylesheet should not cause empty
paragraphs to exhibit vertical whitespace".

See bug 35768 for more details, including links to the relevant posts from W3
people (well, person) to back this up.

Comment 14

[Hixie (not reading bugmail)]

Err, not bug 35768, sorry. I meant bug 35772.