display:table-cell and display:table-row don't apply to input elements

NEW
Unassigned

Status

()

14 years ago
4 years ago

People

(Reporter: ian, Unassigned)

Tracking

({css3, testcase})

Trunk
css3, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
Keywords: css3, testcase
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.
(Reporter)

Comment 3

14 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>.
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.

Comment 6

11 years ago
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

Updated

4 years ago
See Also: → bug 960512
You need to log in before you can comment on or make changes to this bug.