Closed Bug 156888 Opened 21 years ago Closed 14 years ago

{inc} Issues changing display types with anonymous table cells


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






(Reporter: paulsperanza, Assigned: bzbarsky)



(Keywords: testcase)


(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET 
CLR 1.0.3705)
BuildID:    2002053012

When I toggle the style.display of a <tr> object from none to inline or block 
it works correctly the first time. The second time it is toggled to be visible 
the <tr> is moved over to the right the width of itself.

Every time after that it renders the same - to the right.

Please see the sample code in the additional information section of this 

Reproducible: Always
Steps to Reproduce:
Run the HTML attached in the additional information section

1. Click the button 'Toggle Row 4'
2. Row 4 appears in the table
3. Click the button again
4. Row 4 disappears from the table
5. Click the button again
6. Row 4 appears in the table but moved over to the right - the    
   distance of its width.


Actual Results:  The <tr> horizontal position changed.

Expected Results:  Hide and shown the <tr> in the same position every time.

		<title>Row Test</title>
	<script language="javascript">
		function toggleRow(rowId)
			var r = document.getElementById(rowId);
			if ( == "none") = "inline";
			else = "none";
		<table border="1">
				<td>Row 1</td>
				<td>Row 2</td>
				<td>Row 3</td>
				<td id="row4" style="display: none">Row 4</td>
		<input type="button" onclick="toggleRow('row4')" value="Toggle 
Row 4"	
Invalid, I think; IIRC, per the CSS table model, when you change it to inline or
block you start generating anonymous table elements. You should probably be
switching between display: none and display: table-row; does that give you the
effect you want?
Assignee: attinasi → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → amar
Attached file testcase
Isn't the default display inline?
The discussion on bug 114867 is informative. Bug 149913 is essentially the same 
thing also. Maybe a compatibility note is in order?
confirming.  We're not tearing down the pseudo cell frame....
Ever confirmed: true
Depends on: 162063
change platform to all.
also found in solaris 5.8
OS: Windows 98 → All
Summary should be changed? display="inline" is buggy on all elements. See bug
Priority: -- → P3
Target Milestone: --- → Future
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
Isn't the example given in this bug actually in reference to a <td> object and
not a <tr> object?

I think the summary ought to be changed to reflect this. The corresponding
example to <tr> is attached for comparison.
Attached file testcase
References <tr> rather than <td>.
Blocks: 56362
I've had much experience with this bug when attempting to create JS menus 
compatible with multiple browsers.  In fact, on Mozilla, one of the current 
sites I'm working on is using this technique.

Note that this bug is also present when using getElementByName instead of 
getElementById.  Also, using display = "block", which is the method I use, 
also produces this bug.

This affects the <tr> element because the row allocates extra space for the 
cell regardless of whether there is still a cell present.

For another example of this bug, check out
Click on BookSwap to show the submenus.  Then click it again to hide the 
submenus.  Finally, click it once more, and the cell is now to the right of 
where it originally was because the original cell is still taking up space 
when it should not be.

Chad Richards
chad. display:block on a row??? Where did you learn this, from  CSS 2.1? Please
look there and you will find "table-row" as the display type to use.
chad. display:block on a row??? Where did you learn this, from  CSS 2.1? Please
look there and you will find "table-row" as the display type to use.

Actually, no, I was talking about display:block on a <td>, not a row.  I was 
mentioning that the bug APPLIES to the <tr> element not the <td> since the 
<tr> is allocating unnecessary space for a cell that is nonexistent.

Now, according to CSS 2.1,
Floats, absolutely positioned elements, inline-blocks, table-cells, and 
elements with 'overflow' other than 'visible' establish new block formatting 

Also, since,
table    { display: table }
tr       { display: table-row }
thead    { display: table-header-group }
tbody    { display: table-row-group }
tfoot    { display: table-footer-group }
col      { display: table-column }
colgroup { display: table-column-group }
td, th   { display: table-cell }
caption  { display: table-caption }
User agents may ignore these 'display' property values for HTML table elements
, the browsers could choose to ignore the element if not using display:block.

Block-level elements are those elements of the source document that are 
formatted visually as blocks (e.g., paragraphs). Several values of 
the 'display' property make an element block-level: 'block', 'list-item', 
and 'run-in' (part of the time; see run-in boxes), and 'table'. 

Since <td> is a block-level element, it can be displayed using display:block.

Chad Richards
(In reply to comment #14)
> Since <td> is a block-level element, it can be displayed using display:block.

That is not true.
(In reply to comment #15)
> (In reply to comment #14)
> > Since <td> is a block-level element, it can be displayed using 
> That is not true.

Yes, it is.  The best explanation of it, using W3C's definitions, can be found 

i agree with Chad.  If tables, table cells, and rows are not blocks, then what 
are blocks?
Nobody here seems to have been able to give a clear explanation of what's going on, but there are multiple incremental reflow/frame construction bugs here relating to the creation of anonymous table cells.
Summary: style.display on <tr> not correct → {inc} Issues changing display types with anonymous table cells
No longer blocks: 56362
Keywords: testcase
Fixed by checkin for bug 162063.  Added test.
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Assignee: layout.tables → bzbarsky
You need to log in before you can comment on or make changes to this bug.