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

Status: NEW

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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.

Comment 3

[Hixie (not reading bugmail)]

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

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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

Comment 5

[Boris Zbarsky [:bzbarsky, bz on IRC]]

So now you'll get an input, inside some pseudo table boxes.

Comment 6

[Bernd]

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

[Boris Zbarsky [:bzbarsky, bz on IRC]]

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.

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Created attachment 435388 [details]
Testcase