W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: [CSSWG] Minutes and Resolutions 2010-04-21

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 17 May 2010 17:48:04 -0400
Message-ID: <4BF1B994.1090302@mit.edu>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT