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

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

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 6 Sep 2010 13:53:17 -0700
To: Anton Prowse <prowse@moonhenge.net>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20100906205317.GA29069@pickering.dbaron.org>
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 (do they all match?), 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.

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.


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

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


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 6 September 2010 20:53:48 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:50 UTC