Re: [CSS21] More issues with issues with 9.5 (Floats)

On 06/09/2010 22:53, L. David Baron wrote:
> On Monday 2010-09-06 22:39 +0200, Anton Prowse wrote:
>> On 06/09/2010 20:32, L. David Baron wrote:
>>> On Sunday 2010-09-05 10:39 +0200, Anton Prowse wrote:
>>>> A couple more float issues.
>>>>
>>>> Issue 1:
>>>>
>>>> There is excellent interop demonstrating that line boxes are not
>>>> shortened in the presence of floats which appear later in the source
>>>> document (and hence overlap the floats in many situations).  This
>>>> fact is missing from the spec.
>>>
>>> In what such cases does the spec currently say that such a float
>>> should shorten such a line box?  Given rule 6 in section 9.5.1, I'd
>>> think there aren't any such cases, since rule 6 says that any such
>>> float must be below any such line box.
>>>
>>> Or am I misinterpreting what you're saying?
>>
>> Hmm, you're not misinterpreting me, but I must admit that I've
>> always ignored rules 5 and 6 in the context of the float being in a
>> different containing block from the non-floated block or line box
>> respectively. (Rule 5, however, is easily seen to hold when the
>> earlier box is a float, even in that situation.)
>>
>> Are we supposed to interpret those rules as saying that the top
>> margin of the float is adjusted (made negative) in the following
>> test case?
>>
>> <div>text</div>
>> <div style="margin-top:-50px">
>>      <div style="float:left; width:100px; height:100px;
>> background:yellow"></div>
>> </div>
>
> Ah, right.  So this is yet another case where implementations don't
> follow the spec

Yup.

> (do they all match?)

I'll guess so.  (I'm pretty sure I'd have hit upon this in practice if 
they didn't.  I use negative margins /a lot/.)

> , because the spec is written in
> terms of a set of constraints that's easy to map approximately to an
> algorithm, but hard to map precisely to an algorithm.

Indeed.  (I don't claim it's easy to spec this correctly!)

> I suspect we should (a) think about changing rule 6 and (b)
> simultaneously changing the rules about shortening line boxes to say
> that line boxes prior to the line box containing the placeholder to
> the float are not shortened.

Yes.  And (at least part of) rule 5 too.


>>>> 9.5.1 says:
>>>>    # 3. The right outer edge of a left-floating box may not be to the
>>>>    # right of the left outer edge of any right-floating box that is to
>>>>    # the right of it. Analogous rules hold for right-floating elements.
>>>>
>>>> This means a left float can be to the right of a right float.  (They
>>>> need to be in different containing blocks in order to construct this
>>>> situation, obviously.)  Fx3.6 agrees; I haven't tested in others.
>>>> This doesn't cause a problem, but I wanted to seek confirmation that
>>>> this was an intentional feature of the spec.
>>>
>>> I think it is not an intentional feature of the spec
>>
>> Me neither.  It was probably accidentally introduced by the addition
>> of "that is to the right of it" which was no doubt thought to solve
>> the problem of excluding right floats that are entirely above the
>> left float in question.
>>
>>> and it is not
>>> what the spec currently says (since the rules in 9.5.1 apply to all
>>> floats within the same BFC).
>>
>> Sorry, what do you mean that it's not what the spec says?
>
> http://www.w3.org/TR/CSS21/visuren.html#float-rules says "References
> to other elements in these rules refer only to other elements in the
> same block formatting context as the float."
>
> So if you follow the rules in the spec, a left float can't be to the
> right of a right float if they're both in the same BFC.  However,
> you're describing testcases where that actually happens (and I
> believe you, based on my knowledge of Gecko's implementation).

Actually, I can't seem to reproduce this in Gecko any more.  (Foolishly 
I discarded my test case, which was shoehorned into some layout issue on 
a real web page from a while ago.)  But I believe the following test 
case should show the floats side-by-side according to the current spec:

<div style="width:100px">
	<div style="float:right; width:100px; height:100px; 
background:yellow"></div>
</div>
<div style="margin-left:100px; width:100px">
	<div style="float:left; width:100px; height:100px; background:blue"></div>
</div>

Which rule says otherwise?  (Different BFCs are not the issue here; 
rather, it's the unfortunate wording of Rule 3.)


>>> However, because we have interop,
>>> http://wiki.csswg.org/spec/css2.1#issue-101 suggests that we should
>>> change the spec, once somebody comes up with the text for the
>>> appropriate change.
>>
>> Agreed that we need new text there, but that issue is a somewhat
>> different, self-contained problem related to overflow.
>
> I don't think that's a self-contained problem related to overflow.
> It's the general issue that when following the float positioning
> rules, implementations ignore floats whose horizontal position is
> not within the containing block of the float they're positioning.

I probably need to re-read that thread in detail.  I recall concluding 
that the issues shown in your test cases all arose because of overflow 
in one way or another, and that they would all be resolved – that is, 
Gecko's actual behaviour would be regarded as correct in all cases – if 
the spec were to "ignore" overflow (pretend it doesn't exist, by 
truncating boxes at the containing block boundary) for the purposes of 
applying all the layout rules.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 6 September 2010 21:59:39 UTC