- 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