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

On Thursday, January 27, 2011 2:00 PM 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-rel
> > pos-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?

The cases has invalid xhtml there are div elements nested within a span element. That is invalid. If you change them all to span elements and then create a style rule "span span" setting those nested spans to blocks the case should be fine.

IE9 does not currently pass the updated case. This is a blocking issue now since I cannot seem to find any other user agents that pass this other than Firefox.

--
Thanks,
Arron Eicholz

Received on Friday, 28 January 2011 00:00:54 UTC