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

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.

<http://css-class.com/test/temp/ie8-webkit-opera-negative-width.png>


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

<http://css-class.com/test/temp/ie7-negative-width.png>


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.

<http://css-class.com/test/temp/gecko-negative-width.png>


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

<http://www.w3.org/TR/CSS21/visuren.html#line-box>

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

<http://www.w3.org/TR/CSS21/visuren.html#containing-block>

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

<http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr-ap-left.htm>


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