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

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

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/