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

On Mon, May 17, 2010 at 2:48 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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...

That's only because template layout overloads the position property,
which I don't think is a good idea.  I'll get to Template when I'm
done with Flexbox...


>> 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.

Just to make sure, you're talking about this, right?:

<!DOCTYPE html>
<body>
  <span style="display: table-cell">a</span>
  <span style="float: left"></span>
  <span style="display: table-cell">b</span>
</body>

In this case, step 2 of fantasai's revised algorithm won't do anything
special with the float (it's not a child of any table-* box), and so
when step 3.1 tries to generate the missing table-row wrapper, it will
wrap the two cells separately, and eventually form two separate tables
with a float between them.  This is fine with me.

(If <body> was display:table-row or similar, step 2 would wrap the
float in an anonymous table-cell, and then step 3 would put all them
in a single table-row.)

(Also, it might be debatable whether or not 3.1 would actually respond
to the float.  Defining floats as "out-of-flow" is the problem here -
as written, step 3.1 could be interpreted as wrapping all three
<span>s in a table-row, even though the float is *still* not either a
table-cell or wrapped in one.  It could also be interpreted as saying
to wrap the two table-cells in a table-row, but not the float, which
doesn't make any sense in terms of the box tree.)

>>>> * 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

Ah, thanks.


>>>> * 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

Ah, gotcha.  The table box itself, not the anonymous wrapper.


>>> 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 id=a>
>    <div display:table-row id=b>
>      <div display:table-row id=c>
>        <div display:table-cell id=d/>
>      </div>
>    </div>
>    <div position:absolute/>
>  </div>

(IDs added for ease of description.)

The anonymous table-cell that is a child of #b and wraps #c.  So the
abspos would align itself with the content-edge of #b.


>> 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.

Sure.  Do you have a preference on which I should do?  I can go either way.


>>> 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?

Exactly; padding is added to align the contents, but the position of
the table-cell itself (in particular, the position of the border-edge
of the table-cell) doesn't pay particular attention to vertical-align,
except that the bottom edge may be changed by the added padding
pushing it down.

~TJ

Received on Monday, 17 May 2010 23:09:47 UTC