1782 - {compat} DIV acting as P (?) - not backwards-compatible

Status: VERIFIED INVALID

(Core :: Layout, defect, P5)

Description

[Joe Drew (not getting mail)]

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.

Comment 1

[kipp]

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.

Comment 2

[leger]

Setting all current Open/Normal to M4.

Comment 3

[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 4

[rickg]

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.

Comment 5

[Joe Drew (not getting mail)]

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

Comment 6

[Hixie (not reading bugmail)]

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.

Comment 7

[Chris Petersen]

Marking as verified invalid.