Making an <input> into a table-cell destroys the <input> control -- it loses its intrinsic size, its contents, and stops being editable. TESTCASES: http://www.hixie.ch/tests/adhoc/css/box/table/018.html http://www.hixie.ch/tests/adhoc/css/box/table/019.html http://www.hixie.ch/tests/adhoc/css/box/table/020.html This is unfortunate because if targetting browsers that support display:table, one might well want to replace a table with CSS table layout in this way.
Ian, see http://lists.w3.org/Archives/Public/www-style/2005Jan/0062.html I would need to know the answer to the questions that mail raises before I could even start thinking about how to fix this. At the moment, in your testcases, we create table-cell layout objects for the <input>. Since the input-ness of an input is wholly in the layout objects, the <input>s in question naturally cease being inputs. The proble, of course, is that input layout objects in Mozilla can't participate in the table layout algorithms as defined in the CSS specification. So I'd have to do one of the following: 1) Create pseudo table frames around the input (and have it be an input layout object inside an anonymous cell). 2) Rewrite all of the table code in Mozilla somehow to deal with arbitrary layout objects in arbitrary spots in the table. 3) Special-case inputs somehow. 4) Something else? In any case, a response to my mail would go a long way towards a solution here.
One other note. In an XHTML document, the following: <table> <input style="display: table-row"> <td>Text</td> </input </table> will render the text in a table cell in current Mozilla builds. This is almost certainly wrong. Again, it's not clear to me what the right behavior is.
Your e-mail is currently going through the CSS2.1 issues resolution process. And yeah, your second case is definitely wrong -- we should be ignoring (for the purposes of rendering only) any nodes inside <input>.
Note that this is more or less a duplicate of bug 243159, except fixing that one won't fix the issue you want fixed here -- text-input behavior out of something rendering like a table cell. I doubt we'll ever really fix that; it'd require a fundamental redesign of how layout works in Gecko, for very small benefit...
Depends on: 243159
So now you'll get an input, inside some pseudo table boxes.
Boris, Hixies testcases are WFM can we close this? If not what keeps this bug open. Is there a new test case for this?
What keeps the bug open is that we're not making the input into a table cell itself... You would have the same issues with table rows. For example: <tr> <input style="display: table-cell"> <td style="height: 500px"></td> </tr> The input should be 500px tall. Or: <tr> <td>AAA</td> <td>BBB</td> </tr> <input style="display: table-row"> The input should be the same width as the sum of the two cells in the previous row.
OS: Windows 2000 → All
Hardware: x86 → All
Summary: making an <input> into a display:table-cell kills the <input> → display:table-cell and display:table-row don't apply to input elements
Version: 1.7 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.