Open
Bug 281357
Opened 20 years ago
Updated 3 years ago
display:table-cell and display:table-row don't apply to input elements
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
NEW
People
(Reporter: ian, Unassigned)
References
Details
(Keywords: css3, testcase)
Attachments
(1 file)
508 bytes,
text/html
|
Details |
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.
Updated•20 years ago
|
![]() |
||
Comment 1•20 years ago
|
||
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.
![]() |
||
Comment 2•20 years ago
|
||
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.
Reporter | ||
Comment 3•20 years ago
|
||
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>.
![]() |
||
Comment 4•19 years ago
|
||
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
![]() |
||
Comment 5•18 years ago
|
||
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?
![]() |
||
Comment 7•17 years ago
|
||
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.
Updated•15 years ago
|
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
Comment 8•15 years ago
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•