- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 17 May 2010 17:48:04 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
On 5/17/10 5:27 PM, Tab Atkins Jr. wrote: > That's up to the layout mode to specify. Floats aren't out-of-flow in > the same way that abspos are; they *do* interact with the things > around them, they just have a special behavior inside of normal flow. > Abspos, though, makes sense in any flow, and removes the element > entirely from any layout considerations. I don't think the first clause of that last statement is true as long as we allow auto offsets on abspos boxes. For example, I think it's decidedly false in that situation in the template layout case... > I'm fine with table flow just wrapping floats in an anonymous cell, as > they do now. The testcase I'm talking about has the float as a child of the block, note. >>> * the top inner edge of the padding box of the table-row of the first >>> table-cell box following the element >> >> OK. So the top padding edge of the table-row of the first table-cell box >> following the element, right? Guessing at what you meant by "inner edge"; >> or did you mean the content edge instead of the padding edge? > > The edge where the content and padding meet. Couldn't recall exactly > which name to give to that. That would be the content edge. See http://www.w3.org/TR/CSS21/box.html#box-dimensions >>> * the top inner edge of the padding box of the table-row of the first >>> table-cell box preceding the element >>> * the top inner edge of the padding box of the table the element is in. >> >> Which of the two boxes that the table generates are we talking about here? > > What do you mean? A display:table element generates more than one box. See the picture at http://www.w3.org/TR/CSS21/tables.html#model >> I'm not sure it does; in that case it'll put the element lined up with the >> top of the table (for whatever definition of "table"). Unless you're >> defining "following" in a non-obvious way? > > I may be. I include descendants there. So that, for example: > > <div display:table id=a> > <div display:table-row id=b> > <span display:table-cell id=c></span> > </div> > <span position:absolute id=d></span> > <div display:table-row id=e> > <span display:table-cell id=f></span> > </div> > </div> > > ...in this, #d would choose #f via the first rule, as the first > table-cell box following it. OK. That needs a clear definition too. What cell (if any) would be the preceding one in this case: <div display:table> <div display:table-row> <div display:table-row> <div display:table-cell/> </div> </div> <div position:absolute/> </div> > If you don't like talking about descendants of siblings, I can > rephrase it to avoid that. It's just somewhat more verbose, as I have > to explicitly deal with every possibility for siblings. Yes, yes you do.... Either that or make it very clear what you actually mean. >> It's not quite clear to me whether this does sane things with vertical-align >> either, but it probably just doesn't matter. > > It doesn't do anything with vertical-align. Vertical-align aligns the > contents of a cell, not the cell itself. That's not quite the case in CSS2.1 right now. See <http://www.w3.org/TR/CSS21/tables.html#height-layout>. Though maybe that's a matter of interpretation given the padding that ends up added to cells? -Boris
Received on Monday, 17 May 2010 21:48:42 UTC