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

[CSS21] 10.1 Containing block for absolute elements with inline-level ?nearest positioned ancestor

From: Bruno Fassino <fassino@gmail.com>
Date: Tue, 16 Mar 2010 07:33:07 +0100
Message-ID: <da98bce01003152333k126b94c8rc2ebdeedda43b657@mail.gmail.com>
To: www-style <www-style@w3.org>
According to
item 4 subitem 1,
absolutely positioned elements whose nearest positioned ancestor is
inline-level  have a containing block defined using the first and the
last box of the ancestor.
Considering just the ltr case, the first box of the ancestor defines
the top and the left sides of the C.B., the last box defines the
bottom and the right sides.

An inline level element may extend on more lines, so the above implies
that in some cases the _right side_ of the C.B. is 'more' at the left
of the _left side_ of the C.B.. For example here, if 'RR RR' is a
relative positioned inline:


the established C.B. has its right side just at the end of the last R
on the second line, and its left side at the beginning of the first R
on the first line.
I believe this situation is the one described in the spec with:
  "This may cause the containing block's width to be negative"

With Gérard Talbot, I'm in the process of submitting one (or more)
test case about this to the css 2.1 test suite, like for example:

We stopped a bit, because:

1. Although it may be given an interpretation, the above concept of
"negative width" is rather strange.

2. No current browser respects it.  In such cases Safari, Opera, IE8
makes the right side of the C.B. equal to the left side. Using the
'negative width' abstraction, is like they set the width to zero, not
allowing it to become negative.  Only IE7 behaved according to the

Here is a more detailed page describing the situation:

Now the question is:
 - Should the spec be changed to reflect the current browsers' behavior
 - Can we proceed with some test cases that currently no one passes


Bruno Fassino http://www.brunildo.org/test
Received on Tuesday, 16 March 2010 06:33:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:43 UTC