Closed
Bug 156888
Opened 23 years ago
Closed 17 years ago
{inc} Issues changing display types with anonymous table cells
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: paulsperanza, Assigned: bzbarsky)
References
Details
(Keywords: testcase)
Attachments
(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
report.
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.
<html>
<head>
<title>Row Test</title>
</head>
<script language="javascript">
function toggleRow(rowId)
{
var r = document.getElementById(rowId);
if (r.style.display == "none")
r.style.display = "inline";
else
r.style.display = "none";
}
</script>
<body>
<table border="1">
<tr>
<td>Row 1</td>
</tr>
<tr>
<td>Row 2</td>
</tr>
<tr>
<td>Row 3</td>
</tr>
<tr>
<td id="row4" style="display: none">Row 4</td>
</tr>
</table>
<br>
<input type="button" onclick="toggleRow('row4')" value="Toggle
Row 4"
</body>
</html
|
||
Comment 1•23 years ago
|
||
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
|
|
||
Comment 2•23 years ago
|
||
|
|
||
Comment 3•23 years ago
|
||
Isn't the default display inline?
|
|
||
Comment 4•23 years ago
|
||
|
|
||
Comment 5•23 years ago
|
||
The discussion on bug 114867 is informative. Bug 149913 is essentially the same
thing also. Maybe a compatibility note is in order?
|
|
Assignee | |
Comment 6•23 years ago
|
||
confirming. We're not tearing down the pseudo cell frame....
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Comment 8•23 years ago
|
||
Summary should be changed? display="inline" is buggy on all elements. See bug
174704.
|
|
||
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
|
|
||
Comment 9•23 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
|
|
||
Updated•23 years ago
|
Target Milestone: --- → Future
|
|
||
Comment 10•22 years ago
|
||
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.
|
|
||
Comment 11•22 years ago
|
||
References <tr> rather than <td>.
|
|
||
Comment 12•21 years ago
|
||
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 http://wig.uark.edu/beta
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
|
||
Comment 13•21 years ago
|
||
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.
|
|
||
Comment 14•21 years ago
|
||
>>
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
contexts.
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.
Furthermore,
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
|
||
Comment 15•21 years ago
|
||
(In reply to comment #14)
> Since <td> is a block-level element, it can be displayed using display:block.
That is not true.
|
|
||
Comment 16•21 years ago
|
||
(In reply to comment #15)
> (In reply to comment #14)
> > Since <td> is a block-level element, it can be displayed using
display:block.
> That is not true.
Yes, it is. The best explanation of it, using W3C's definitions, can be found
here: http://www.ahuka.com/htmllevel1/blocklevel.html
--Chad
|
|
||
Comment 17•21 years ago
|
||
i agree with Chad. If tables, table cells, and rows are not blocks, then what
are blocks?
http://www.w3.org/TR/CSS21/visuren.html#display-prop
|
|
||
Comment 18•20 years ago
|
||
|
|
||
Comment 19•18 years ago
|
||
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
|
|
Assignee | |
Comment 20•17 years ago
|
||
Fixed by checkin for bug 162063. Added test.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
|
|
Assignee | |
Updated•17 years ago
|
Assignee: layout.tables → bzbarsky
You need to log in
before you can comment on or make changes to this bug.
Description
•