- From: Alan Gresley <alan@css-class.com>
- Date: Thu, 18 Mar 2010 04:25:04 +1100
- 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. <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