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

Bert Bos wrote:
> On Wednesday 21 January 2009, Anton Prowse wrote:
>> 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;
> 
> There is a known contradiction in the spec that we decided to not solve 
> in CSS 2.1. 
> [...]
> However, there was a desire to handle especially tables differently. 
> Unlike images, but like line boxes, tables often *can* be made 
> narrower. We only became aware of this new requirement very late and 
> decided to permit UAs to do this if they believed they had a reasonable 
> way to do it, but write down the actual rules only in level 3.

Interesting history, thanks!

> Thus there now is a vague sentence that says that certain blocks ("BFC" 
> blocks, or "flow roots" as is the shorter term currently in level 3) 
> *may* become narrower and move sideways rather than down, even though 
> that contradicts the rules of section 10.3 about computing the width of 
> a block. Section 10.3 will thus have to be rewritten in level 3.

[Well, it's only a contradiction if it's not clear that the vague 
sentence overrides 10.3 -- and that 10.3 is permitted to be overridden 
by the vague sentence.  Although I've always regarded that as "obvious", 
perhaps it would be better to be more explicit in the spec that this is 
the case.]

> We have no idea yet by how much a block may become narrower.

Sure.

> Maybe it is possible to define an automatic rule that takes the "intrinsic minimum 
> size" (a term that is going to be defined in level 3) into account, or 
> maybe we'll need a new property that lets the designer decide if and by 
> how much a block can become narrower.

Interesting.

However, the more I think about this, the more I think that there are 
two unrelated but similar issues here.  On the one hand, there's  "is it 
possible to make this block narrower? How much narrower can it feasibly 
be?".  On the other hand, there's the issue of whether, given a block 
which can be narrowed and whose minimum feasible width is less than or 
equal to the "space next to the float", the margin edge of the block 
should slide under the margin edge of the float or abut it.  Obviously, 
the available "space next to the float" depends on the answer to the 
latter question.  It's the latter issue rather than the former which I 
was raising, and superficially it seems possible to "solve" the latter 
issue in CSS21 while leaving the former to CSS3.

Note that all the major desktop browsers will narrow CSS21 BFCs in 
general, not just tables (the original use-case).  As I noted before, 
the browsers are divided as follows:

B's left margin edge touches F's right margin edge: Fx1.5.0.12/win; 
Op9.62/win; Op10a/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;

Even if this issue is intentionally left unspecified in CSS21, authors 
still want cross-browser compatibility.  Before lobbying one group or 
the other (and with the window for changes very nearly closed on IE8), I 
guess I'm just looking for input from implementors and other interested 
parties as to whether they have a strong preference one way or the other 
on the two possibilities.  It's interesting that Opera changed sides 
unilaterally for the 9.62 release, after Firefox had already changed 
sides in the other direction!

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

Received on Wednesday, 25 February 2009 14:41:08 UTC