W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [CSS21] Resolution to Issue 229 is flawed

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 27 Mar 2011 22:28:11 +0200
Message-ID: <4D8F9DDB.4050208@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
On 17/03/2011 03:17, Anton Prowse wrote:
> I've run out of time to go into any detail right now, but I wanted to
> express that I'm unhappy with the resolution to Issue 229 [...]
> because it doesn't address my
> original issue, it makes too many easy-to-handle cases undefined for the
> different issue that it does handle, and it's also editorially flawed:
> "if a float's position is foo then its position is undefined" is
> self-contradictory; it can't be undefined if it's possible to determine
> that it's foo!

Issue 229 (currently summarized as "Floats' effect on lines above 
placeholder") in fact concerns how implementations don't match the rules 
in 9.5.1 that describe where to position a float.  For example, rules 5 
and 6 state that, within the block formatting context in which it 
participates, the top margin edge of a float cannot be higher than the 
top margin edge of any source-preceding float or in-flow block(*), nor 
higher than the top of any line box containing source-preceding boxes. 
In practice these rules are consistently violated; a float can often be 
higher than source-preceding line boxes and blocks _in different 
containing blocks_.  Indeed, the spec recognizes this elsewhere, such as 
in the resolution to Issue 274 ("line boxes are not shortened next to 
later floats") and in 9.5 (between the Examples):
   # A float can overlap other boxes in the normal flow (e.g., when a
   # normal flow box next to a float has negative margins).
Such situations are constructed using negative margins, not on the float 
but on some other source-preceding (possibly ancestor) box.  For 
example, there is excellent interop for the following test case:

<body style="width:100px">
	<div style="background:yellow">
		<span>text text text text text text text text text text text text 
text</span>
	</div>
	<div style="background:orange; height:20px; margin-bottom:-80px"></div>
	<div style="background:green; width:10px; height:10px; float:left"></div>
</body>

and good interop for this one:

<body style="width:100px">
	<div style="background:yellow">
		<span>text text text text text text text text text text text text 
text</span>
		<span style="background:blue; width:10px; height:10px; float:left"></span>
	</div>
	<div style="background:orange; height:20px; margin-bottom:-80px"></div>
	<div style="background:green; width:10px; height:10px; float:left"></div>
</body>

(Fx, IE and Op refuse to move the green float higher than the blue one; 
only Sf ignores the blue one.)

The current resolution to Issue 229 is to make undefined the position of 
a float when a source-preceding box has a negative vertical margin.  IMO 
this is wildly heavy-handed.  It makes an entire class of cases 
undefined, including cases where the negative margin makes no difference 
whatsoever to the rules in 9.5.1 such as:

<body style="width:100px">
	<div style="background:orange; width:120px; height:20px; 
margin-bottom:-10px"></div>
	<div style="background:yellow">
		<span>text text text text text text text text text text text text 
text</span>
	</div>
	<div style="background:green; width:10px; height:10px; float:left"></div>
</body>

As we've discussed many times before, floats were originally spec'd with 
very little consideration for things in other containing blocks.  I 
propose a less aggressive resolution to Issue 229.  Firstly, change 
rules 5 and 6 to restrict consideration to the same containing block as 
the float:

   | 5. The outer top of a floating box may not be higher than the outer
   |    top of any floated or in-flow block generated by an element
   |    earlier in the source document that shares the same containing
   |    block–establishing element as the float.
   | 6. The outer top of an element's floating box may not be higher
   |    than the top of any line-box containing a box generated by an
   |    element earlier in the source document that shares the same
   |    containing block–establishing element as the float.

Secondly, change the recently-added text:

   # But in CSS 2.1, if, within the block formatting context, there is
   # an in-flow negative vertical margin such that the float's position
   # is above the position it would be at were the negative margin set
   # to zero, the position of the float is undefined.

to:

   | But in CSS 2.1, if there is another floated box generated by an
   | element earlier in the source document whose containing block is
   | established by a different element than that for the float, and
   | there is an in-flow negative vertical margin such that the other
   | floated box influences the application of rule 5, then the position
   | of the float is undefined.

I think this does the trick, and it only makes a much smaller class of 
cases undefined (and one where there is already imperfect interop).


[I stand by my criticism (quoted above) of the current resolution, 
including the observation that, quite apart from technical issues, it's 
editorially flawed.]


(*) Actually, rule 5 doesn't say "in-flow"; that's what it mean to say, 
though.  This needs editorial fix-up!


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Sunday, 27 March 2011 20:28:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT