Closed Bug 121960 Opened 18 years ago Closed 18 years ago

Problems rendering height of table when adding DOCTYPE


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






(Reporter: linczak.1, Assigned: karnaze)





(3 files)

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?
Reporter could you please verify that your bug is not the 68th dupe of bug 22274.
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.
 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: . 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.
Ever confirmed: true
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 
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 ;)
Attached file Test case in an html
 setting the priority of this bug and changing the OS to ALL
OS: Windows ME → All
Priority: -- → P3
 Is think this is dupe of bug # 44264 
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?
Target Milestone: --- → mozilla1.2
no, this is not a dupe of previously mentioned bugs
( and

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

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..
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.
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.
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.
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 .

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.
I found an article that explains this problem.
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.

Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.