changing display of a TR from "block" to "none" to "block" doubles initial row height




Layout: Tables
15 years ago
15 years ago


(Reporter:, Unassigned)


Windows 2000

Firefox Tracking Flags

(Not tracked)




15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.4) Gecko/20030529

If you change a TR dispal from "block" to "none", it hides the row, but doesn't
decrease table height.
If you change a TR display style from "none" to "block", it displays the row AND
it increases the row height from row original size !

If use "table-row" instead of "block", the problem doesn't occur

Reproducible: Always

Steps to Reproduce:
1. Display the HTML code given as example
2. click on "show/hide", it hides correctly the row
3. click on "show/hide", it shows the row, with a "block" display style
4. click on "show/hide", it hides the row, but doesn't decrease row height.
5. click on "show/hide", it shows the row, and increases row height.

Actual Results:  
Displayed row height is twice original row height

Expected Results:  
I think the bug is on step 4 : when switching from "block" to "none", height
should have been decreased.

Here is a HTML testcase : 

function toggle(object) {
  var style = document.getElementById("row_"+object).style;

<table border="1">
  <tr><td><a href="javascript:toggle('pending');">show / hide</a></td></tr>
  <tr id="row_pending" class=""><td colspan="3">AAA</iframe></td></tr>

Comment 1

15 years ago
<TR> is not a block element it is a table-row element
</IFRAME> shouldn't be in there
that said I see this too if you really want to change the <TR> element to a
block element
LInux 2003061211

Comment 2

15 years ago
Invalid because TR is not a block element.  In CSS it is a table-row element. 
Reference the duped bug.

*** This bug has been marked as a duplicate of 198886 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
The CSS2 spec has very clear rules for how to handle elements within tables that
have the "wrong" display type.  This bug is only invalid if our behavior is
correct according to those rules.  Is it?

(That said, using the correct display type (or "") is an easy workaround for the

Comment 4

15 years ago
I'm going by the observation in bug 198886 comment 1.  If that's not accurate,
then one of these bugs needs to be reopened.

Comment 5

15 years ago
Dbaron: Besides, you also seemed to indicate that this behavior is correct (and
the bug invalid) in the past when displaying an element as a non-default non
table-* type.  Referencing bug 122316.

Also referencing BZbarsky's comments in invalid bug 149993.  I presume that this
behavior is expected to be as such when toggling any table element to block
instead of to a table-* type.
CSS2 clearly defines what should happen for various combinations of display
types on table-related elements.  What CSS2 describes may confuse authors whose
expected behavior is "what IE does".  That does not mean that our behavior is
correct for every case of toggling display types on table elements.

Comment 7

15 years ago
Then we've been resolving a lot of bugs invalid without making that call on what
Mozilla should be doing.  ::shrug::

I leave it to someone else to decide what, if any, bugs to reopen.
Which bugs other than this one and bug 198886 (which I already reopened and
marked duplicate) do you think have been marked invalid without proper analysis?
 (Just because the bug doesn't have a full explanation of why our behavior is
correct doesn't mean that analysis wasn't done in somebody's head.)

Comment 9

15 years ago
Based on what you've said, any bug (such as the ones I've cited -- I know I've
seen more like those but I'm not turning Bugzilla upside down today to try and
find them) where:

* a table element was toggled to a non table-* display value
* the result broke the layout (or didn't emulate IE)
* the bug was resolved invalid (or dup of a previous invalid) on the basis of or similar logic
In the ones you cited I think people were properly making the call on what
Mozilla should be doing.
You need to log in before you can comment on or make changes to this bug.