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

Re: block-in-inline-relpos-002 invalid (and was Issue 138 resolution sufficient?)

From: Alan Gresley <alan@css-class.com>
Date: Thu, 23 Dec 2010 16:56:01 +1100
Message-ID: <4D12E471.1020807@css-class.com>
To: "L. David Baron" <dbaron@dbaron.org>
CC: public-css-testsuite@w3.org, www-style@w3.org
On 23/12/2010 6:58 AM, 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).

I don't believe this is true. See.

<http://css-class.com/test/temp/css21-issue-138-simple-float-test-with-more-tests.htm>

The parent <span> seems to be relatively positioned in all test in FF 
3.6.13, Opera 11, IE8 mode in IE9 beta and IE9 beta. Test (3), (4) and 
(5) shows this better with the <span> before or after with display: 
block. Safari 5 does not seem to relatively positioned the parent <span>.

I side note, I don't understand why the border boxes of the parent 
<span> in some test are offset 200px left from the float's right edge. 
This seems bazaar. IE8 mode in IE9 beta and IE9 beta seem more 
consistent in all test.


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

The floats should be positioned on the left edge of it's nearest 
block-level element according to 9.5. In other words, it's containing 
block's left edge .  IE8 mode in IE9 beta and IE9 beta ignore this.

> I haven't tested IE9.

All floats are positioned 200px left from the their containing block's 
left edge.

> So I think making the change that the summary of issue 138 seems to
> suggest (which I think was always a mis-summarization of the issue)
> would be a rather large change, given the high level of interop
> between implementations other than IE8.  My inclination would be to
> just fix the test so that Gecko and Chromium pass, since I believe
> their behavior is correct.

On the surface this is true but the parent <span>s are all over the place.

> But I'd be interested in data on what IE9 does, and also interested
> if the Opera developers could defend their third alternative as
> correct behavior.
>
> -David

In regards to CSS2.1 issue 138.

    Does relatively positioning a float's parent also offset the float?

I say they should not if the parent box is display-inline.


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

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Thursday, 23 December 2010 05:56:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:35 GMT