- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 22 Jan 2009 23:08:08 -0500
- To: fantasai <fantasai.lists@inkedblade.net>
- CC: www-style@w3.org
fantasai wrote:
> Can I get a bug #?
For which, exactly?
> I agree with Tab,
> <ul style="display: table">
> <li style="display: table-cell"/>
> <li style="display: table-cell"/>
> </ul>
> needs to work.
OK, I can live with that.
While we're here, all that discussion was about the cell/row/rowgroup
aspect of things. There's also the colgroup/column aspect. If we
require a table around cells, I see no problem with requiring it around
columns as well. There is currently no requirement that column groups
be synthesized around columns directly in a table, as far as I can tell,
so that would leave nothing else to be done here.
That said, the currently specified behavior for a table-cell child of a
table-column-group is to generate a table, rowgroup, and row between
them, right? And then nothing happens with this box? In general, it's
not clear what happens with boxes that are descendants of
table-column-groups and aren't table-columns, or boxes that are
descendants of table-columns. I would vote that all of these should
just be suppressed.
So my proposal is that this section should look as follows:
1) Leave the current rule 1.
2) Change rule 2 to say that in that situation the table-row box
is suppresed.
3) Change rule 3 to say that in that situation the table-column box
is suppressed
4) Change rule 4 to say that in that situation the row group, column
group, or caption is suppressed.
5) Drop rule 5.
6) Change rule 6 to say that the child box should be suppressed.
7) Change rule 7 to say that the child box should be suppressed.
8) Change rule 8 to say that the child box should be suppressed.
9) Make it clear that the rules need to be applied in this order.
Otherwise rule 6 could suppress the cells above before rule 1
has a chance to create the table row.
10) Make it clear that children of table-column boxes and
non-table-column children of table-column-group boxes should
be suppressed.
This will leave one area where things are a little weird, and that's in
handling rows directly inside a table. Per the spec as it stands it
sounds like no rowgroup should be wrapped around the rows. At the
moment, Gecko will put anonymous rows inside a rowgroup that spans as
many rows as it can, so that this HTML:
<table>
<tr>
<td rowspan="0">Spanning the whole table?</td>
<td>Second column</td>
</tr>
<tr><td>Second column?</td></tr>
</table>
renders identically to this XHTML:
<table xmlns="http://www.w3.org/1999/xhtml">
<tr>
<td rowspan="0">Spanning the whole table?</td>
<td>Second column</td>
</tr>
<tr><td>Second column?</td></tr>
</table>
It looks like these also render identically in Opera and Safari. Safari
ignores the rowspan, while Opera treats it as Gecko does (spanning the
whole table). Wrapping each row in a separate <tbody> makes both Gecko
and Opera not span past the first row, so both seem to be generating a
rowgroup around the rows in the XHTML case, or at least treating the
layout as if such a rowgroup exists. In the case of Gecko we do in fact
generate the rowgroup. It might make sense to require this behavior,
though I can't offhand think of a way the difference can be detected
other than this rowspan="0" thing... That would be a rule inserted
between my proposed rule 1 and rule 2.
-Boris
Received on Friday, 23 January 2009 04:09:01 UTC