W3C home > Mailing lists > Public > www-style@w3.org > February 2009

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

From: Bert Bos <bert@w3.org>
Date: Tue, 24 Feb 2009 15:38:50 +0100
To: www-style@w3.org
Message-Id: <200902241538.50471.bert@w3.org>
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. The way floats and width computations have been defined 
since CSS1 (and are still defined in CSS 2.1) leads to only two 
possibilities when a float and a block collide:

  - Either the line boxes inside the block are shortened so as not to
    overlap the float, or

  - if that is not possible, the line boxes or other content are shifted
    down to below the float. E.g., if the content consist of a table or
    a wide image, it has to be moved down.

In no case do the top, left and right edges of the float and the block 
change. The only edges that may change are the bottom edges of the 
block, which may become lower than if there were no float.

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.

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.

We have no idea yet by how much a block may become narrower. 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.

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Tuesday, 24 February 2009 14:39:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:24 UTC