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

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.

I haven't tested IE9.


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.

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

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

Received on Wednesday, 22 December 2010 20:00:11 UTC