- 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