Re: block-in-inline-relpos-002 invalid

On 28/01/2011 8:59 AM, L. David Baron wrote:
> On Wednesday 2010-12-22 14:58 -0500, L. David Baron wrote:
>> On Wednesday 2010-10-13 23:36 -0700, L. David Baron wrote:
>>> http://test.csswg.org/suites/css2.1/20101001/xhtml1/block-in-inline-relpos-002.xht
>>> and its HTML equivalent, are, as far as I can tell, invalid.
>>>
>>> It would probably make sense if they were valid, though.
>>>
>>> (That said, Gecko implements the current spec.)
>>>
>>> However, the rules for float positioning in section 9.5 are very
>>> clearly written in terms of the position of the float's containing
>>> block, and nothing in the section on relative positioning overrides
>>> that.
>>>
>>> Given the description of issue-138 in the issue tracker:
>>> http://wiki.csswg.org/spec/css2.1#issue-138
>>> I'd have hoped that it would have fixed this issue.  However, the
>>> resolution for the issue only clarified the position of floats
>>> contained within blocks inside a relatively positioned inline, and
>>> didn't do anything to define relative positioning as moving floats
>>> that are descended from a relatively positioned inline without a
>>> block that is an ancestor of the float and descendant of the inline.
>>
>> I've looked into this issue a bit further.  I added to my previous
>> test for issue 138 by turning it into:
>> http://dbaron.org/css/test/2010/css21-issue-138-simple-float-test-with-more-tests
>>
>> Gecko trunk, Chromium trunk, and Opera 11 all agree on this test
>> (only item (2) is relatively positioned).  Firefox 3.6 had a
>> different behavior in which items (2) and (5) were relatively
>> positioned, because we did block-inside-inline wrapping incorrectly
>> as described in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=501847#c1 and fixed in
>> the same bug.  IE8 has a different behavior in which it relatively
>> positions all five items.
>>
>> Chromium trunk and Gecko trunk have the same ("failing") behavior
>> on:
>> http://test.csswg.org/suites/css2.1/20101210/html4/block-in-inline-relpos-002.htm
>> though Opera 11 has a different "failing" behavior.  IE8 and Firefox
>> 3.6 "pass" the test.  I'd note that this test in the testsuite is
>> testing only item (5), which is an edge case compared to the other
>> items (especially (1) and (2)).  I also suspect that the test was
>> written on the assumption that the incorrect Gecko behavior in
>> Firefox 3.6 and earlier is actually correct behavior, given that I
>> see no other reason for the test to exercise that case.
>
> For the record, I just added a sixth item to this test:  the float
> inside a block inside a relatively-positioned inline.
>
>
> In any case, I adjusted the test so that I believe it is correct;
> patch to the test is attached.  The basic idea of the changes is
> that the spec says that floats are positioned relative to their
> containing block.  Therefore, they are moved by relative positioning
> of an inline only when there is a block inside that inline that is
> the containing block for the float, and is moved since 9.2.1.1 says:
>    # When such an inline box is affected by relative positioning, the
>    # relative positioning also affects the block-level box contained
>    # in the inline box.
>
> The test had previously been testing that floats contained within
> a relatively positioned inline *without* a block intervening were
> affected by relative positioning, which is incorrect.  Therefore, I
> adjusted the test to:
>   * assume that the .float.L and .float.R are not affected by
>     relative positioning (by swapping their colors and no longer
>     relative positioning .float.R)
>   * add a float inside the nested block that is affected by relative
>     positioning
>
> This leads to the test passing in Gecko (Firefox 4 beta).  It still
> does not pass in WebKit or Opera, because they do not appear to
> implement the part of 9.2.1.1 quoted above.  Maybe it passes in IE9?
>
>
> fantasai, could you review the attached diff?
>
> -David


David,

Your test are testing this.

>    # When such an inline box is affected by relative positioning, the
>    # relative positioning also affects the block-level box contained
>    # in the inline box.


Some of the examples in your test case clearly shows that the inline 
boxes are flowing around their nested floats. So if the inline boxes 
position is due to flowing around the floats, then how can the the 
floats in-turn be positioned in respect to their containing blocks?

Another way of saying it is, how can the floats be positioned in respect 
to their containing blocks  when these containing blocks are positioned 
due to flowing around the floats?

I did reply to this issue last month [1] and created this supporting 
test case [2].


1. 
<http://lists.w3.org/Archives/Public/public-css-testsuite/2010Dec/0180.html>
2. <http://css-class.com/test/temp/block-in-inline-relpos.htm>


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Saturday, 29 January 2011 09:13:58 UTC