I'm not sure if a DIV tag should also act as a P tag. In Communicator 4.x, it does not insert the line feeds that are present in NGLayout. The HTML 4.0 spec says that div tags can insert linefeeds, but it doesn't show it adding extra linefeeds in-between: "Visual user agents generally place a line break before and after DIV elements, for instance: <P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV> which is typically rendered as: aaaaaaaaa bbbbbbbbb ccccc ccccc" The above URL (well, the top-left cell) shows the problem: "Why I don't like stuff" should be on one line, and "or, why do you bug me" should be on the next line, right-aligned. At least, this is what happens in Communicator.

Well, according to the HTML DTD, P's only can contain "inline" objects and DIV's can contain "flow" (which includes P's and inlines). Therefore, our pareser produces a content model that has the DIV container not inside the P that preceeds it. This leads to the extra vertical whitespace. Now its debatable if the parser should do this when using the nav-dtd as its not compatible with navigator. I'm reassigning it to rick to deal with the compatability issues.

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

Per the 4.0 DTD: <P> contains <DIV>, but <DIV> doesn't contain <P>. The whitespace issue aside, this is a correctly formed content model.

URL now references a new testcase. Also valid is the HTML 4.0 spec testcase in the first comment.

According to CSS, the test case mentioned above is correctly rendered by Mozilla. (Every <P> element has top and bottom margins of 1em). Regarding the quote from the spec in the first comment, the spec is giving a TYPICAL rendering, not a CORRECT rendering. The CSS-aware and correct way of rendering <P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV> ...would be: aaaaaaaaa bbbbbbbbb ccccc ccccc ...since, again, <P> elements have top and bottom margins of 1em. This is exactly what we do. The only whitespace issue I see on the original test page is an issue concerning the line-height of images being apparently too tall, and that, again, is actually correct according to CSS. (If instead of using <font size> you used the CSS font-size property, it would work well.) I am marking this bug INVALID, since all three issues are correct according to the specs.

Marking as verified invalid.