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.

Setting all current Open/Normal to M4.

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

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

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

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]

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

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.

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

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.

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

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

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

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.

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