- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 06 Oct 2010 12:44:43 -0400
- To: Bert Bos <bert@w3.org>
- CC: W3C style mailing list <www-style@w3.org>
On 10/6/10 12:28 PM, Bert Bos wrote: > Is that really desired? It seems to me that the anonymous table cell > isn't a good choice for a containing block, because you cannot put > properties on it. If the "inner" element has 'width: 50%', you want > that to be 50% of something that you can control. When using tables, you often do really want it to be of the cell (whose width is very rarely set on the cell itself, and is often determined by the other contents of the cell and by the contents of cells in other rows). > (The example is a bit artificial, too. When you use table layout, you > typically have at least a 'display: table' or a 'display-table-cell' > somewhere.) Sure. The problem is the same if the outer div is display:table. >> (which does not have an element associated with it, last I checked, >> contrary to the "each box is associated with an element" claim above, >> by the way). > > The anonymous table cell is one of the boxes of the "row" element, in my > view. That element has, in this example, two boxes: a row and a cell > (which happen to coincide). That doesn't match the way the claim is being used here, as far as I can tell... Furthermore, nowhere does the spec actually say what you just said. Perhaps it should. > 2. For other elements, if the element's position is 'relative' > or 'static', the containing block is one of the following: > a. If the element is a 'run-in' that is rendered inline in a > sibling element, then its containing block is the content > edge of the principal box of that sibling. > b. Otherwise, if the parent has a principal box that is a block > container box (e.g., if the parent is a 'table-cell' or > a 'block'), then the containing block is the content edge of > the parent's principal box. > c. Otherwise the containing block is the same as that of the > parent. By the way, did I understand correctly that the containing block for abs pos descendants of a run-in that runs into a rel-pos block is NOT the block the run-in ran into, unlike for floats? > Still no anonymous boxes that establish containing blocks, and I think > that is correct. Take this example: > > <div id=outer style="height: 20em"> > Some text<button style="height: 50%">before</button> the image. > <img src="x.png" alt="x" style="display: block"> > </div> > > The text is wrapped in an anonymous block box, but the height > of the BUTTON is 50% of the "outer" element, not of that anonymous box. That looks good, yes. > Here is another example, a variation of Boris's: > > <div id="outer"> > <div id="cell" style="display: table-cell"> > <div id="inner"/> > </div> > </div> > > The containing block of "inner" is the content edge of "cell", because > "cell" is a block container. Yes, of course. My example was very carefully written to NOT have the parent of "inner" be a table-cell. > Another variation, very similar to the one above: > > <div id="outer"> > <div id="table" style="display: table"> > <div id="inner"/> > </div> > </div> > > The containing block of "inner" is the content edge of "table", because > "table" is a block container. It is? Where does it say that? > Boris's original example is different, because a row box is not a block > container: > > <div id="outer" style="height: 20em"> > <div id="row" style="display: table-row"> > <div id="inner" style="height: 50%"/> > </div> > </div> > > The containing block of "inner" is now the content edge of "outer." If > that is surprising, then maybe the issue is that the table row is not > considered. I don't believe it is a problem that the anonymous cell is > ignored. After all, you can't even see it. Again, that doesn't match existing implementations. And you can see the boundaries of that cell if the table has column borders, no? And they may well not match the boundaries of the row in the admittedly odd case of a table with more than one column. ;) -Boris
Received on Wednesday, 6 October 2010 16:45:17 UTC