Re: [CSS21] 9.5.1: placing floats above earlier blocks & line boxes

On 14/10/2010 05:33, Peter Moulder wrote:
> Note that this message merely makes more explicit an issue hinted at in the
> thread "More issues with issues with 9.5 (Floats)".  That thread deals with the
> fact that earlier line boxes aren't shortened in implementations; while this
> one deals with the related issue that implementations are placing floats next
> to those earlier line boxes in the first place.
>
> All implementations I've tested seem to ignore rule 6 and the "earlier block"
> part of rule 5 (but not "earlier float" part), for line boxes&  blocks that
> have a different containing block (but in same BFC of course).
>
> I.e. in the example:
>
>    <p>Blah.</p>
>    <p>Blah.</p>
>    <p>Blah.</p>
>    <p>An earlier block and line box</p>
>    <p style="margin-top: -6em;"><span style="float:left;">A float.</span></p>
>
> all user agents I've tested place the float above "An earlier block and line
> box", thus contravening both rules 5 and 6.
>
> (Whereas they do honour the "earlier float" part of rule 5,
> i.e. the new float won't get placed above a float child of that earlier block.)

> I must say that as someone without much CSS authoring experience, I can't say
> I like the idea of allowing floats to overlap previous text, and I have
> difficulty seeing the use cases.

Ah, but the underlying explanation in the specific subcase you're 
discussing is that the float *isn't* overlapping previous text, apart 
from visually.  (I'm aware that this sounds curious; please bear with 
me!)  Hence no Rule is being contravened.

Most of the layout framework of CSS - at least at the block-level level 
(sic) - revolves around the margin box.  We can think of the box tree as 
being laid out using rectangular outlines representing the margin box, 
and only afterwards once these rectangles have jostled for position do 
things actually get painted on the canvas with colours and text and so 
on.  The key to understanding negative margins is that the only thing of 
interest at this level is the location of outer edges, not the values of 
the margins themselves.  For example, in the following test case

<div>some text</div>
<div style="float:left; width:10px; height:10px; margin-top:-5px"></div>

the float's top margin edge sits *strictly below* the "some text" div, 
whilst its bottom margin edge sits precisely -5px+10px=5px below that. 
The height of the float's margin box is 5px, despite its border area 
height being 10px.  Hence the float doesn't overlap the "some text" at 
all; it's a 5px-high box below the "some text".  Now, when painted, of 
course there's visual overlap of the float border box; but that's 
irrelevant to layout.

For me, this setup (which holds for negative margins in general, not 
just in cases involving floats) is logical and viable from various 
perspectives including the author perspective, and in the case of floats 
I don't think that line boxes should be shortened next to the border box 
of the float, only next to the margin box.  [Note that if the top margin 
of the float were made more negative in my example above, we'd end up 
with at float whose margin area height were zero or negative, even 
though its border area height would remain positive.  In my opinion, 
this should result in a float which has no effect on layout (impotence 
again!), and indeed this is what I argued for in yet another couple of 
related float issues [1,2] about zero- and negative-width/height floats, 
the 'height' version of which is Issue 185.]

By comparison, the example I gave in [3] as part of the thread the Peter 
mentions did not concern a float whose margin box started below the 
text.  Rather, I very intentionally pulled the float upwards visually 
using a negative margin on a /wrapper box/ around the float.  That meant 
that the float's margin area box moved upwards, and that example and 
thread did succeed in demonstrating that current UAs do not implement 
Rules 5 and 6 as current specified.

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

[1] http://lists.w3.org/Archives/Public/www-style/2010Aug/0100.html
[2] http://lists.w3.org/Archives/Public/www-style/2010Aug/0182.html
[3] http://lists.w3.org/Archives/Public/www-style/2010Sep/0148.html

Received on Thursday, 14 October 2010 17:52:53 UTC