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

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

From: Alan Gresley <alan@css-class.com>
Date: Thu, 18 Mar 2010 04:25:04 +1100
Message-ID: <4BA11070.1070307@css-class.com>
To: Bruno Fassino <fassino@gmail.com>
CC: www-style <www-style@w3.org>
Bruno Fassino wrote:
> According to
>   http://www.w3.org/TR/CSS21/visudet.html#containing-block-details
> 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:
> ............................RR
> RR
> 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"

This I think is referring to when there is a reversal of the 
direction. The above spec is a note to this line.

# In the case that the ancestor is inline-level, the containing
# block depends on the 'direction' property of the ancestor.

# If the 'direction' is 'ltr', the top and left of the containing
# block are the top and left padding edges of the first box
# generated by the ancestor, and the bottom and right are
# the bottom and right padding edges of the last box of the
# ancestor.

In your test case, the ancestor has the same direction and since the 
relative positioned element is inline [1], then it can not have any 
width at all.

# The 'width' property does not apply.

> 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:
>   http://brunildo.org/test/ts/containing-block-inline.html
> 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.

This is plainly seen when the inline element with position relative 
has almost wrapped to a new line.


> Only IE7 behaved according to the
> spec.

Almost but in such circumstances IE7 loses all sense of where the 
containing block ends (in the case it right edge) when there is a line 


Gecko handles this worst since the absolutely positioned element id to 
the right of what should be the containing block. Again when there is 
a line break.


> Here is a more detailed page describing the situation:
> http://www.brunildo.org/test/inline-cb.html

Very good test case Bruno.

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

I believe that the spec should reflect current browser behavior but I 
would say that many test case must be created first.

I see the definitions of what a 'containing block' [1], 'initial
'containing block' [2], 'block formating context' [3] and 'overflow' 
[4] very ambiguous at the best.

What should happen to an element with position relative when there is 
a line break?


# A relatively positioned box keeps its normal flow size,
# including line breaks and the space originally reserved
# for it. The section on containing blocks explains when
# a relatively positioned box establishes a new containing
# block.

Firstly what does "a relatively positioned box keeps its normal flow 
size" mean?

Following onto the later part of what we see above when a relatively 
positioned box establishes a new containing block (the spec '9.1.2 
Containing blocks' does not even explain this), are we really seeing 
something like overflow?


# Each box is given a position with respect to its containing
# block, but it is not confined by this containing block; it
# may overflow.

BTW, absolute positioning and overflow works in the reverse when you 
use rtl direction.


1. <http://www.w3.org/TR/CSS21/visudet.html#inline-width>
2. <http://www.w3.org/TR/CSS21/visuren.html#containing-block>
3. <http://www.w3.org/TR/CSS21/visudet.html#containing-block-details>
4. <http://www.w3.org/TR/CSS21/visuren.html#block-formatting>
5. <http://www.w3.org/TR/CSS21/visufx.html#overflow>

Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Wednesday, 17 March 2010 17:25:45 UTC

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