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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 06 Sep 2010 22:39:57 +0200
Message-ID: <4C85519D.4000802@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: "L. David Baron" <dbaron@dbaron.org>
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 style="margin-top:-50px">
     <div style="float:left; width:100px; height:100px; 

But that doesn't gel with the position of the "indicator" text in the 
following test case:

<div style="width:150px">text text text text text text text text text 
text text text text text text text text text</div>
<div style="margin-top:-50px; background:gray">
     <div style="float:left; width:100px; height:100px; 
background:yellow; margin-top:20px"></div>
     indicator indicator indicator
     <div style="clear:left"></div>

I think you've hit upon deeper trouble here.  As we've both pointed out 
in the past, it's obvious that floats in different containing blocks 
from nearby boxes were not given consideration when speccing the float 

(When I raised this issue I was actually referring to the text in 9.5 

   # line boxes created next to the float are shortened to make room for
   # the margin box of the float.

which, even with the new definition of "next to",[1] doesn't exclude the 
case of line boxes next to later floats.  By contrast, 9.5.2 ('clear') 
is careful to talk about clearing an *earlier* floated box.)

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

> 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.  (Specifically, 
related to whether overflow is taken into consideration when applying 
the layout rules; I argued that it shouldn't be,[2] although I concede 
that it's probably more fiddly to implement that way.)

[1] http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html
[2] http://lists.w3.org/Archives/Public/www-style/2009Mar/0078.html

Anton Prowse
Received on Monday, 6 September 2010 20:40:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC