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

On Mon, May 17, 2010 at 12:58 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/17/10 3:34 PM, Tab Atkins Jr. wrote:
>>>
>>>  <!DOCTYPE html>
>>>  <body>
>>>    <span style="display: table-cell">a</span>
>>>    <span style="position: absolute"></span>
>>>    <span style="display: table-cell">b</span>
>>>  </body>
>>>
>>> Every single browser I have here (IE8, recent Webkit, recent Gecko, Opera
>>> 10.5) creates two rows (and in fact two tables, as a slightly more
>>> careful
>>> testcase shows) in this case, not one table with one row.
>>
>> Right, in my ideal world that would create a single table.  Abspos
>> should be treated exactly as display:none for the purpose of the table
>> algo.
>
> Again, what makes abspos special here?  Should float also be thus treated in
> the above case?  What about any future out of flows we may introduce (e.g.
> things repositioned via advanced layout?)?

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'm fine with table flow just wrapping floats in an anonymous cell, as
they do now.  The one weird case is when an element is both
display:table-cell and float:left.  The cleanest possible
implementation would, imo, ignore the float, but I'm okay with the
current behavior where the float overrides the display instead.

Future out-of-flow methods we introduce would work similarly.  If they
do something that makes sense regardless of the flow they're in, then
they should act like display:none.  If not, then the flow manager
should specify how they are to be treated.


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


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


>> I think this properly covers cases where, frex, you have the abspos
>> between two table-rows.
>
> 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.

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.


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

~TJ

Received on Tuesday, 18 May 2010 00:14:24 UTC