121960 - Problems rendering height of table when adding DOCTYPE

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect, P3)

Description

[Jonathan Linczak]

This seems like a bug to me, despite the whole description of the quirks mode.  
This page demonstrates the error.  The site has a DOCTYPE declared for XHTML 
1.0 Transitional, along with a table whose height is only 3 pixels in height.  
This is supported by an image whose height is only 3 pixels.  However, Mozilla 
renders this with some abnormally large height.

When the DOCTYPE is taken away from the page, the table displays the correct 
height of 3 pixels.  What could be going on here?

Comment 1

[Bernd]

Reporter could you please verify that your bug is not the 68th dupe of bug 22274.

Comment 2

[Jonathan Linczak]

No, I think this bug is a little bit different, although I am experiencing 
spacing problems between tables as well.  The problem here isn't spacing.  The 
problem is the fact that Mozilla renders a 3-pixel high column as something 
much larger than that, and only when the DOCTYPE is added for XHTML 1.0 
Transitional.  When that DOCTYPE is removed, the height is rendered correctly.  
I haven't found a bug that exactly talks about this problem.

Comment 3

[Amarendra Hanumanula]

 The problem is with the height of the spacer.gif image when a doc type is 
mentioned. The image height is rendered incorrectly. Go to 
URL: http://www.xigole.com/test . The footer has the same space.gif problem. The 
footer height is bigger than it should be. Compare with IE to differenciate the 
problem.  I am attaching a zif file which has 1) HTML Testcase describing the 
problem 2) a image. unzip the zip file into a folder and view it.
 

Comment 4

[Amarendra Hanumanula]

Attachment: testcase and spacer.gif image in the zip file

Comment 5

[Jonathan Linczak]

Yes, I just viewed your attachment and I was surprised to see exactly what you 
were describing.  I guess no it is a matter of finding out if this bug can be 
fixed...

Comment 6

[Javier Kohen]

I just happen to have found this bug, too.
I'm presenting another test case, this time no images are involved, but there's
a variation introduced by a FORM tag. The symptoms are the same Jonathan reported.

In this example you can see an abnormaly tall box, and another one that looks
correct. The difference is simple, the form tag has been removed from the later.
The box is a table inside a td from another table. It seems the form tag is
getting the extra height, as you can see in incorrect case, where the internal
table receives a different color than the container cell.

As in the original report, removing the DOCTYPE tag "fixes" the problem.

I'm using version "Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.7)
Gecko/20020121" as packaged by Debian in 2:0.9.7-5 (so you know whom to blame if
you can't reproduce it ;)

Comment 7

[Javier Kohen]

Attachment: Test case in an html

Comment 8

[Amarendra Hanumanula]

 setting the priority of this bug and changing the OS to ALL

Comment 9

[Amarendra Hanumanula]

 Is think this is dupe of bug # 44264 

Comment 10

[Jonathan Linczak]

Sorry, I don't understand everything that they are commenting on in that bug (I 
am not a developer, just an advocate for the W3C standards - aren't we all!) 
but it doesn't seem like they are commenting on some of the problems that we 
have been having.  Our bug stems from the DOCTYPE declaration and how it fails 
to properly display the heights of a column in a table when certain objects are 
inside of the table.  Does anyone disagree with this?

Comment 11

[Dennis Jakobsen]

no, this is not a dupe of previously mentioned bugs
(http://bugzilla.mozilla.org/show_bug.cgi?id=22274 and
http://bugzilla.mozilla.org/show_bug.cgi?id=44264)

i have the same issue..  and 4 pages that confirm it..  www.tomshardware.com
is one of them..   the other 3 are quite small and serves as great testcases..

http://www.apple.com/trailers/touchstone/signs/

click any of the 3 quicktime movies and you'll see the table placement issue..

Jonathan, I hope this is the same you're describing..

Comment 12

[Dennis Jakobsen]

Attachment: Table example with quicktime plugin content.

Open this in Composer in Normal or Preview mode. Then resize the composer
window and the updating/refreshing goes berserk, trying to place the quicktime
movie 3 places at once.

Comment 13

[Jonathan Linczak]

Actually, I did notice the Quicktime content moving around, but that was it.  I
saw no problems with tables on the other sites that you gave.  My problem stems
from the fact that the DOCTYPE, when declared as XHTML 1.0 Transitional, renders
tables incorrectly by adding spacing between rows that it shouldn't be, and is
also adding added height to rows when it shouldn't be.  The original URL had to
be taken away, but I have it at a new URL now.  However, to make it work for
everyone, I had to comment out the DOCTYPE declaration (such a shame since I
went through all the trouble to make it XHTML compliant and comply with Web
Accessibility Guidelines).  If you find anything else like what I am describing
(other than the attachments created earlier) please let me know.

Comment 14

[Joshua Nixon]

this doesn't seem to be limited to just tables - i've been stuck trying to
convert to xhtml compliant pages and my nav bar generated using fireworks is
shot because of faulty table layout if xhtml doctype is added. in an attempt to
fix this in any way possible i dropped the table and tried to use a stack of
images separated by line breaks. same result. n4.x, ie6 render the table or
stack of images correctly every time regardless of doctype. n6.2 and mozilla
build 2001122106 display correctly only after removing doctype or changing
doctype to html 4.01 transitional. any attempts to fix this using css have so
far been unsuccessful; mozilla ignores margin/border/padding requests for the
table or images. can't find anything in w3c xhtml specs asking for spacing in
tables by default, thought i was going insane until i found this bug report.

Comment 15

[Andrew Clover]

Amarendra's testcase shows the inline-image issue - this is, as suspected, a dup
of bug 22274. It really is. Use 'display: block' on the image and the cell is
3px high in Standards Mode. If you do not understand why Mozilla is doing what
it does please read 
http://developer.netscape.com/evangelism/docs/articles/img-table/ .

Javier's testcase seems just to show that <form> has a default margin. Change it
to <form style="margin: 0;"> and both cells are about the same. no bug.

Dennis's testcase is interesting - I see the plug-in flicker between the middle
and the top of the screen whilst resizing the window (it appears in the correct
place when resizing ends). However I don't believe this is anything to do with
the problems mentioned by other posters.

Comment 16

[eric_schmidt]

I found an article that explains this problem.

http://developer.netscape.com/evangelism/docs/articles/img-table/

Comment 17

[Mats Palmgren (inactive)]

The original reported problem here has been fixed, see bug 153032 "Implement
almost-standards rendering mode".

The problem reported by Javier Kohen 2002-01-31 is a separate issue and not a
bug. The first top-margin and last bottom-margin in a cell is only eliminated
in compat mode.

-> WORKSFORME