Re: [CSS21] Proposal for a replacement for section 17.2.1 (table anonymous objects)

On 3/30/10 2:00 AM, fantasai wrote:
>> I assume you mean "out of flow" here? Has there been an alternate
>> proposal on that?
>
> No, I mean abspos. AFAICT, floats just get wrapped in a block and turned
> into a table cell. No?

Ah, yes.  True.  It's not obvious that this should be the case, of 
course; the fact that table cels happen to be float containing blocks by 
default but not abs pos containing blocks by default is more or less an 
accident, right?

>> What I wrote down is what UAs seem to implement, as I recall.
>
> Yes, but it doesn't make sense unless you know the internals of a layout
> engine.

Perhaps, but neither do various other things in CSS2.1.  And again, this 
one happens to be interoperably implemented across all major rendering 
engines.

Note that it's not clear to me that other proposals would make "sense" 
either (e.g. for auto-offset abs pos, the concept of "where it would be 
if it were in the flow" becomes even more tenuous than usual if you 
don't create a table cell to mark the spot).

In any case, I have yet to see a concrete counterproposal; any such 
counterproposal would currently be considered at risk (since not a 
single UA actually implements it).  If people have concrete suggestions, 
I'm willing to at least listen, I guess.  ;)

> Hmm, yeah. the rules in step 2 are backward. Try this?
>
> | 2. Generate missing child wrappers:
> | 2.1 If a child C of a tabular container is not a 'table-cell',
> | then generate an anonymous 'table-cell' box around C and all
> | consecutive siblings of C that are not 'table-cell' boxes.
> | [current rule 8]
 > | 2.2 If a child C of a row group box is not a 'table-row' box, then
 > | generate an anonymous 'table-row' box around C and all consecutive
 > | siblings of C that are not 'table-row' boxes.
 > | [current rule 7]
 > | 2.3 If a child C of a 'table' or 'inline-table' box is not a proper
 > | table child, then generate an anonymous 'table-row' box around C
 > | and all consecutive siblings of C that are not proper table children.
 > | [current rule 6]

That doesn't quite work.  Consider:

   <div style="display: table">
     <div></div>
     <div style="display: table-row">
       <div style="display: table-cell">R2,C1</div>
       <div style="display: table-cell">R2,C2</div>
     </div>
     <div style="display: table-cell">R3,C1</div>
     <div style="display: table-cell">R3,C2</div>
   </div>

The expected rendering here (in the "Opera/Webkit/Gecko do it; haven't 
tested IE8" sense) is a table with three rows and two columns; the first 
row has one cell containing the block, the second row is the table-row 
div, and the third row is an anonymous row wrapping the two table cells.

But rule 2.1 above would create an anonymous table-cell box around the 
block and the table row, then the amended rule 2.2 would create a 
table-row around that cell and the two remaining cells.  So you get a 
table with one row and three cells; the first cell itself will contain a 
block and then an anonymous table (generated by rule 3.2) containing the 
R2,C1 and R2,C2 cells.

For what it's worth, I haven't sat down and proved this, but I believe 
that the behavior Gecko currently implements (as well as the behavior 
Webkit currently implements and the behavior Gecko used to implement 
until I touched this stuff recently) can't actually be expressed as a 
"fill in the parents, then the kids" or "fill in the kids, then the 
parents" kind of process; it actually requires that loop over several 
steps that I had in my original proposal.  I haven't studied Opera's or 
IE's behavior in enough detail (a lot more work to do it without the 
source and all) to comment on those.

If we think that loop is an issue (why?), then we need to figure out 
what we actually want the behavior to be, I guess.  Maybe item 2 from my 
original post is just a necessary wart; it's certainly better than the 
alternative given above...  But again, I think this is all only a 
problem if we insist on writing out this process as effectively 
straight-line code.  Though I suppose all our loops are finite-length 
(just with embedded branches) so we could unroll it all.  I suspect the 
result wouldn't be very readable, though.

> Change
> | consecutive
> | Two sibling boxes are consecutive if they are both in flow and have no
> | intervening in-flow siblings.
> to
> | consecutive
> | Two sibling boxes are consecutive if they are both in flow and have no
> | intervening in-flow siblings other than, optionally, an anonymous inline
> | containing only white space.

Will there always be only one anonymous inline in the situation above? 
Even if the preformatted whitespace contains linebreaks?

If so, sounds fine.  If not, then we should allow zero or more such inlines.

-Boris

Received on Tuesday, 30 March 2010 06:37:11 UTC