167321 - Additional padding at the bottom of <TD> depending on </TD> placement

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect, P3)

Description

[José Luis Domingo López]

Create a table, a couple of rows, and a table cell on each row. Place a <IMG...>
inside each cell. The interesting part could be:
<table width="512" height="256" cellpadding="0" cellspacing="0" border="5"
bgcolor="#444444">
<tr>
    <td width="512" height="128"bgcolor="#880000">
        <img src="missing.png" width="512" height="128"></img>
    </td>
</tr>

This code generates a cell where there is a little padding below the image. With
the same table definition above, but with a less beautiful indentacion you get
what you (at least me) expect: no additional padding.
<tr>
    <td width="512" height="128"><img src="top_image.png" width="512"
height="128"></img></td>
</tr>

There are several combinations of tag placement that give "correct" and
"incorrect" results. For example, the following also renders OK:
<tr>
    <td width="512" height="128">
        <img src="bottom_image.png" width="512" height="128"></img></td>
</tr>

However, the following renders incorrect:
<tr>
    <td width="512" height="128"><img src="missing.png" width="512"
height="128"></img>
    </td>
</tr>

Having read HTML 4.01 recommendation I have not seen anything with respect to
differences in presentation related to end tags placement.

Comment 1

[Sebastian Biallas]

Could you add an example? Does removing the doctype (if any) help?
Mostlikely this is bug bug 22274 (read:
http://devedge.netscape.com/viewsource/2002/img-table/ )

Comment 2

[José Luis Domingo López]

I have created a couple of "test-cases" to make it clearer. They consist of a
table with two rows with just a cell on each, and a simple PNG the same size.

* "Incorrect" rendering. With DOCTYPE (without it, you get the same result):
http://www.24x7linux.com/bugs/mozilla/167321/incorrect.html

* "Correct" rendering: like the above, just placing </td> in other places:
http://www.24x7linux.com/bugs/mozilla/167321/correct.html

* "Correct" rendering using CSS: exactly as the first example, but with an added
style/css "td img {display: block;}" (as seen on
"http://devedge.netscape.com/viewsource/2002/img-table/"):
http://www.24x7linux.com/bugs/mozilla/167321/correct_css.html

Having read the URL Sebastian Biallas gave
(http://devedge.netscape.com/viewsource/2002/img-table/) I see this is indeed
something known, but what was confusing me is the fact that depending on where
you place </td> the result changes, and I think is the same problem with maybe
rwo different causes. It seems when the closing </td> is in a different line
where the closing </img> is, you get the added padding. Maybe this additional
newline gets interpreted as text and the padding is just the baseline placement
described in the URL pointed by Sebastian ?.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Those pages are in quirks; sounds like our quirks inline box model has a problem
in this case?

Comment 4

[Kolya]

I would like to add that I have this Bug on Win98 too. The content of the cell 
is a Flash-Movie.
This is an old Netscape-Bug that Netscape had almost a year before. It was an 
annoyance to anyone creating websites. 
Netscape has resolved it by now but Mozilla seems to have "reinvented" it.
I tried the workaround described on this page ("Correct" rendering using CSS)
but it did not work. I also wouldn't  recommend fooling around with CSS since 
the Bug can be bypassed simply by transfering the final </td>-tag into the last 
line of the cell-content.




 

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.. with a current build, the testcases in comment 2 all look identical.    	
José, are you still seeing a problem?

Comment 6

[José Luis Domingo López]

I have just tested with my current FireBird version (Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7) and all test cases in comment
number 2 are identical, and seem correct.

I don't have a Mozilla around here , but seems this bug is now gone.

I should have tracked this bug closer, sorry.

Comment 7

[Boris Zbarsky [:bzbarsky]]

We don't know what fixed this...