Re: [CSS2.1-9.5] [CSS2.1-9.4.1] Block formatting context and Floats

fantasai wrote:
> Anton Prowse wrote:
>> 9.5 (Floats) states that the border box of an in-flow block formatting 
>> context B must not overlap(*) any float F in the same block formatting 
>> context P as the element itself, but does not refer to the margin box 
>> of B.  [Other floats, being out of flow, are excluded from this 
>> requirement; this is in keeping with the following sentence higher up 
>> in 9.5 which does explicitly refer to the margin box: "a floated box 
>> is shifted to the left or right until its outer edge touches the 
>> containing block edge or the outer edge of another float".]
>>
>> On the other hand, 9.4.1 (Block formatting contexts) states that a box 
>> B's
>> left outer edge touches the left edge of the containing block P, even in
>> the presence of the float F, unless B establishes a new block formatting
>> context (in which case B may become narrower due to the presence of F).
>>
>> Then, irrespective of whether or not B becomes narrower, if the UA 
>> decides
>> that B can sit next to F and if the left margin of B is less than the sum
>>     s = (left margin of F) + (border area width of F) + m
>> then B must be shifted rightwards away from the left edge of the 
>> containing
>> block P.  The issue is that it is not clear by how much. 
> 
> The "unless" excludes BFCs from needing to connect their outer edges with
> edges of the containing block. As for by how much, it would have to be at
> least enough to prevent overlap, but the spec explicitly leaves the 
> narrowing
> effect undefined, so the position of its edge is therefore also undefined.
> 
> So, am I understanding correctly that you want that position (and therefore
> exactly how much the block gets narrowed) to be defined?

Well, either it should be defined or IMO the spec should be more 
explicit in how it is undefined.  There are four sensible options:

B's left margin edge touches F's right margin edge;
B's left border edge touches F's right margin edge;
B's left margin edge touches F's right border edge;
B's left border edge touches F's right border edge;

Of these, only the first two occur in the major browsers, judging from 
the rendering of a simple test case[1], and we see that even the very 
latest versions of these browsers do not agree on the behaviour:

B's left margin edge touches F's right margin edge: Fx1.5.0.12/win; 
Op9.62/win; IE8PB1;
B's left border edge touches F's right margin edge: Fx3.0.5/win; 
Fx3.2b2/win; Op8.54/win; Op9.27/win; Sf3.2.1/win; IE6; IE7;

That only the first two options are implemented makes reasonable sense, 
since a float's margin is "solid" everywhere else in the spec and so one 
would not expect it to be ignored here.

I would prefer the behaviour to be defined, although I am indifferent as 
to which is chosen, and I confess to not being aware of /any/ examples 
in the wild where a non-floated BFC sits next to a float(*) and where 
the author is relying on a particular rendering result, as alluded to by 
Boris Zbarsky[2], so I can't fully evaluate why a particular one might 
be preferable.  (Not that I doubt him.)

(*) Note that adjacency of two floats is a different matter, is 
explicitly defined (as being the first option), and is a common and 
reliable method of achieving grid-like "multi-column" layouts.

However, if it is to remain undefined I think it should be explicitly 
stated that the first two options are the only acceptable possibilities.

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

[1] 
http://dev.moonhenge.net/css21/test-cases/block-formatting-contexts/block-formatting-contexts-next-to-floats.html
[2] http://lists.w3.org/Archives/Public/www-style/2008May/0226.html

Received on Wednesday, 21 January 2009 21:15:18 UTC