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

On Mon, May 24, 2010 at 11:32 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/24/10 2:12 PM, Tab Atkins Jr. wrote:
>>
>> After drawing some more diagrams, looks like these are the rules we need:
>
> The element tree doesn't include pseudo-elements, so the rules need to be
> adjusted for that.

Hmm, right.


> You're also missing inline-table in some places in there, I think.

Yeah, I am.  Any place where it mentions table, it should mention
inline-table.  Damn you, combined display property!


>> If an abspos element meets one of the following criteria:
>>   1. It has two immediate siblings, and both are display:table-* (not
>> display:table).
>>   2. It has one immediate sibling, that sibling is display:table-*
>> (not display:table), and its parent is display:table or
>> display:table-*.
>>   3. It has no siblings, and its parent is display:table or
>> display:table-*.
>
> Ok....  There's some whitespace issues in here, unless your definition of
> "immediate sibling" covers those.

It needs to.  Making sure it acts properly wrt whitespace should be
relatively simple here.  We just want to match the behavior of the
table-repair algorithm.  Something like "For the purposes of the
algorithm, a sibling is an element or a run of text immediately
adjacent to the abspos element, or with only whitespace separating it
from the abspos element."  (We're ignoring whitespace whether it's pre
or not, right?)


>> ...then use the first of the following rules that matches to determine
>> the auto position of the element:
>>   1. If its following sibling is display:table-cell, the auto position
>> is the upper right of the border box of the sibling.
>
>  <body style="display: table">
>    <div style="position: absolute"/>
>    <div style="display: table-cell"/>
>  </body>
>
> Putting that abs pos div at the top right corner of the table cell doesn't
> make any sense.
>
>>   2. If its preceding sibling is display:table-cell, the auto position
>> is the upper left of the border box of the sibling.
>
> Or did you just get this rule and rule #1 slightly backwards?

Argh, I can't believe I reversed the left/right there.  My diagrams
are right, I'm just unable to tell left from right.  So yeah, reverse
left/right in all the rules there.  >_<


> This actually raises a really interesting question I hadn't thought about
> before, though.  Consider:
>
>  <body style="display: table">
>    <div style="display: table-footer-group">A</div>
>    <div style="position: absolute">B</div>
>    <div style="display: table-row-group">C</div>
>  </body>
>
> This will put the abs pos at the top left of the rowgroup, if I read your
> markup correctly.  So the rendering will look like:
>
>  A
>  B overlapping C
>
> On the other hand, this markup:
>
>  <body style="display: table">
>    <div style="display: table-row-group">C</div>
>    <div style="position: absolute">B</div>
>    <div style="display: table-footer-group">A</div>
>  </body>
>
> will render as:
>
>  B overlapping A
>  C
>
> That is, everything in the rendering is the same except where the abs pos
> kid is.  Is that desirable, or just acceptable?

Hmm.  That's acceptable, but if it's weird, we can just expand the
[row|header|footer]-group rules into separate clauses, so it'll bind
to the row-group preferentially, which we probably want.  Any
preference on whether header/footer should be expanded, or is it okay
to leave them as the same clause and just bind to whichever it runs
into first?

~TJ

Received on Monday, 24 May 2010 19:37:21 UTC