[css-position][css2] Behavior of an abspos child of a block splitting a relpos inline

I'll open with the markup example, so it's obvious what I'm talking about:

<!DOCTYPE html>
<div class=container>
  foo foo foo
  <span class=inline>
    bar bar bar
    <div class=block>
      <div class=abspos>baz</div>
    </div>
    bar
  </span>
  foo foo
</div>
<style>
.container { border: thin dotted; width: 130px; }
.inline { border: thin solid; position: relative; }
.block { border: thick dotted red; }
.abspos { position: absolute; background: lime; top: 0; right: 0;}
</style>

In other words, we have a relpos inline element (the <span
class=inline>), which is split by a block (the <div class=block>).
The block has an abspos child (the <div class=abspos>).  What's the
abspos's containing block?

I can't find anything in CSS2 that actually specifies this.  The
containing-block language in 10.1 talks about the element-tree, which
suggests that the containing block should still be generated by the
inline, but that seems slightly nonsensical here.  In any case, no
browser does that.

I feel like there are two reasonable answers:

1. The ICB, as the nearest containing block generated by an ancestor
in the box tree.
2. The block, as it magically inherits *some* aspects of the
relative-ness of its inline parent element already.  (In particular,
it gets moved by any relative offsets.)

However, neither Chrome nor Firefox matches either of these, or each
other.  Chrome *almost* makes it the block: top/bottom/left appear to
comport with the *border box* establishing the containing block
(rather than the padding box, as normal), but the behavior of 'right'
doesn't seem to make any sense.

Firefox appears to use the inline element parent, but only uses the
first fragment to determine t/r/b/l.  (This appears to be its normal
behavior, too; this is technically allowed by CSS2 by virtue of it
being undefined, but does not match the Position spec.)

What do?

~TJ

Received on Monday, 28 March 2016 23:32:06 UTC