- From: Bruno Fassino <fassino@gmail.com>
- Date: Tue, 16 Mar 2010 07:33:07 +0100
- To: www-style <www-style@w3.org>
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" 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. Only IE7 behaved according to the spec. Here is a more detailed page describing the situation: http://www.brunildo.org/test/inline-cb.html 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 -- Bruno Fassino http://www.brunildo.org/test
Received on Tuesday, 16 March 2010 06:33:42 UTC