W3C home > Mailing lists > Public > www-style@w3.org > October 2010

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

From: Peter Moulder <peter.moulder@monash.edu>
Date: Thu, 14 Oct 2010 15:33:39 +1100
To: www-style@w3.org
Message-id: <20101014043339.GA17024@bowman.infotech.monash.edu.au>
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>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.)

A couple of relevant quotes from the above-referenced thread:

Anton Prowse:

AP> I must admit that I've always
AP> ignored rules 5 and 6 in the context of the float being in a different
AP> containing block from the non-floated block or line box respectively.
AP> (Rule 5, however, is easily seen to hold when the earlier box is a
AP> float, even in that situation.)

L. David Baron:

DB> I suspect we should (a) think about changing rule 6 and (b)
DB> simultaneously changing the rules about shortening line boxes to say
DB> that line boxes prior to the line box containing the placeholder to
DB> the float are not shortened.

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.  I'd have thought it easy enough to implement
rule 6 as written (though I'll grant it nevertheless does have some
implementation cost compared to the behaviour I see implemented).

So aesthetically (though speaking in ignorance of authoring practice) I hope
that rule 6 stays as written, but there are obviously some good practical
reasons why we might change rules 5 & 6 to match what seems like interoperably
implemented behaviour.

Received on Thursday, 14 October 2010 04:34:10 UTC

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