Re: [CSS21] Concern about anonymous table objects and whitespace

On Thu, Jan 22, 2009 at 10:08 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> 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.

Agreed.

> 7) Change rule 7 to say that the child box should be suppressed.

I do see *some* value in keeping this rule, however.  The second
example in the spec should be possible without extra markup.  However,
I also recognize the problems that this causes - as written, I think
this would force us to wrap inter-cell whitespace with anonymous
table-cells as well, unless we employ some extra heuristics that the
spec currently doesn't define (and that you expressed are very
annoying to deal with).

I am comfortable with accepting this change, though, on the knowledge
that the Generated and Replaced Content Module, if it ever advances,
will allow us to solve this use-case with the following CSS:

row { display: table-cell; }
row::outside { display: table-row; }

> 8) Change rule 8 to say that the child box should be suppressed.

There is no rule 8?  (At least, not in the draft I'm looking at, from
the link in your original mail to this thread.)

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

Agreed.

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

Agreed.  The behavior of Gecko (and likely the Opera behavior as well)
makes the most sense.


So it seems that your proposed algorithm boils down to these rules
(padded out for exactitude, necessary because purging some of the
anonymous-box creations violates some assumptions about table
validity):

1.  If the parent P of a 'table-cell' box T is not a 'table-row', a
box corresponding to a 'table-row' will be generated between P and T.
This box will span all consecutive 'table-cell' sibling boxes of T.

2.  If the parent P of a 'table-row' box T is not a
'table-header-group', 'table-footer-group', or 'table-row-group' box,
a box corresponding to a 'table-row-group' element will be generated
between P and T.  This box will span all consecutive sibling boxes of
T that are 'table-row' boxes.  T and T's siblings may also be
anonymous 'table-row' boxes generated by rule 1.

3.  If the parent P of a 'table-column' box T is not a
'table-column-group' box, a box corresponding to a 'table-column-box'
element will be generated between P and T.  This box will span all
consecutive sibling boxes of T that are 'table-column' boxes.

4. If the parent P of a 'table-row-group', 'table-header-group',
'table-footer-group', 'table-column-group' or 'table-caption' box T is
not a 'table' or 'inline-table', T is suppressed.

5. If a child T of a 'table' or 'inline-table' box P is not a
'table-header-group', 'table-footer-group', 'table-row-group',
'table-column-group', or 'table-caption' box, T is suppressed.

6. If a child T of a 'table-row-group', 'table-header-group', or
'table-footer-group' box P is not a 'table-row' box, T is suppressed.

7. If a child T of a 'table-row' box P is not a 'table-cell' box, T is
suppressed.

8. If a child T of a 'table-column-group' box P is not a
'table-column' box, T is suppressed.

9. The children of a 'table-column' box are suppressed.

Preceding this algorithm would be a note that these rules must be
followed in order.  (Strictly, you must execute 1 first, followed by 2
and 3 in either order, followed by 4-9 in any order.)

Rules 1-4 correct layout upwards, starting with table cells (repaired
by wrapping in a row), moving to rows and columns (repaired by
wrapping in a row-group or column-group) and finishing with everything
else (which get suppressed if they don't have a proper parent).  Rules
5-9 correct layout downwards, verifying that only correct children are
preserved and suppressing everything else.

Sanity check?

~TJ

Received on Friday, 23 January 2009 15:09:02 UTC