- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sun, 27 Mar 2011 22:28:11 +0200
- 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 UTC