Closed
Bug 156888
Opened 22 years ago
Closed 15 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•22 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•22 years ago
|
||
Comment 3•22 years ago
|
||
Isn't the default display inline?
Comment 4•22 years ago
|
||
No. See http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/html.css#233
Comment 5•22 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•22 years ago
|
||
confirming. We're not tearing down the pseudo cell frame....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 8•22 years ago
|
||
Summary should be changed? display="inline" is buggy on all elements. See bug 174704.
Updated•22 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 9•21 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Updated•21 years ago
|
Target Milestone: --- → Future
Comment 10•21 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•21 years ago
|
||
References <tr> rather than <td>.
Comment 12•20 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•20 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•20 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•20 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•19 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•19 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•19 years ago
|
||
Comment 19•17 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•15 years ago
|
||
Fixed by checkin for bug 162063. Added test.
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Assignee | ||
Updated•15 years ago
|
Assignee: layout.tables → bzbarsky
You need to log in
before you can comment on or make changes to this bug.
Description
•