6233 - {compat} nested font tags badly parsed

Status: VERIFIED DUPLICATE of bug 991

(Core :: DOM: HTML Parser, defect, P3)

Description

[patrick]

The type attribute of the <ul> tag on http://www.eage.nl/student specifies the
list items to be started with a square, but only the first one is displayed
with a square. However, the individual <li> tags are seperated by <p> paragraph
breaks which might reset the "type" property. The latest IE and NS browsers
display squares for the full list.

Comment 1

[Hixie (not reading bugmail)]

Actually, the <li> elements *contain* the empty <p> elements, they are not
separated by them.

Here is a distilled example that shows what the real problem is:
   <font> <p> Before <font> Inside </font> After </p> </font>
This renders as two lines (broken at the first nested font).

In StrictDTD you should be refusing to cope with this at all. In CNavDTD mode
you should be parsing the <font> the same way as you parse <em> (the above
snippet renders "ok" using <em> instead of <font>).

Comment 2

[rickg]

There is a screen redraw bug here, but the list items do appear as square rects.
Is there something related to this problem that I'm missing?

Comment 3

[Hixie (not reading bugmail)]

Put the following into one file, on its own:

   <font> <p> Before <font> Inside </font> After </p> </font>

It should render as one line (for compatability) render as one line. Currently,
a line break appears between the words Before and Inside.

Comment 4

[Hixie (not reading bugmail)]

This is definitely still a problem. Look at the following page:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/font.html

The problem is that <font> is being treated differently to <em> as far as
compatability goes (note, this is only a problem w.r.t. compatability mode).

For example, the following:

   <em> <p> Hello </p> </em>

...makes the paragraph italics. However, the following:

   <font color="#FF0000"> <p> Hello </p> </font>

...does not make the paragraph red.

This is inconsistent behaviour.

Comment 5

[rickg]

Harish -- this is simply another residual style problem.

Comment 6

[harishd]

*** This bug has been marked as a duplicate of 991 ***