- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 14 May 2012 15:16:05 +0200
- To: www-style@w3.org
- CC: Simon Sapin <simon.sapin@kozea.fr>
On 11/05/2012 13:47, Simon Sapin wrote: > Le 11/05/2012 13:21, Simon Sapin a écrit : >> But if I read the appendix literally, a line box directly in a table >> cell is never painted. I think it is... just about. It's covered by step 7.2 where "element" refers to the current item indexed by the loop that's initiated in 7. In particular, the case where "element" refers to a table box (which is always a block-level descendent of its BFC-establishing table wrapper box) gives the result, provided one accepts that a line box of a cell is also a line box of the table box itself. However, you're right to pick up on the fact that replaced tables cells can't be so easily hand-waved aside. > Actually, this is probably a better fix: change step 7 from > > > Otherwise: first for the element, then for all its in-flow, > > non-positioned, block-level descendants in tree order: > > to: > > > Otherwise: first for the element, then for all its in-flow, > > non-positioned, block-level and table-cell descendants in tree order: > > This new fix handle replaced cells as well. > Yes, this seems like the correct fix. [Tables cause us no end of problems is CSS21. I wish they'd been pulled out and stuck into a css3-tables spec instead! Indeed, CSS21 is written rather as if the tables chapter were already a separate spec, and the problem is that table details bleed into other chapters rather than having the concepts from the other chapters handled thoroughly and independently in the tables chapter. What's interesting, though, is that many of the issues being raised on them (overflow, painting order, etc.) will apply equally to flexbox and other layout models too.] Cheers, Anton Prowse http://dev.moonhenge.net
Received on Monday, 14 May 2012 13:16:44 UTC