- From: Bert Bos <bert@w3.org>
- Date: Tue, 24 Feb 2009 15:38:50 +0100
- To: www-style@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 -- 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