Insufficient margins/padding for list-items/quotes/etc. next to floats

Look at the following document:

data:text/html,<!doctype html><div style="float:
left;padding:1em;margin:0 1em 1em 0;border:1px solid
black;height:5em">Floated text</div><ul><li>Badly-displayed
bullet</li></ul><p>A paragraph.</p><ul
style="clear:left"><li>Properly-displayed bullet</li></ul><p>Another
paragraph</p>

The first bullet looks wrong: it's not indented relative to the
surrounding text.  This is because the extra padding is left behind
the float, and doesn't actually push the text (or bullet) out past the
surrounding text.  This problem arises pretty commonly on Wikipedia.

Currently there's no good solution that I can think of.  You could
make the list its own block formatting context or wrap it in a table,
but that will mean that if it extends past the float, it won't wrap
back to the left side of the page, leaving an ugly gap under the
float.  On the other hand, you could increase the right margin on the
float, but that will only fix the problem if there's no non-list-item
text on the right.

My initial thought is a new property, inherited, like (names not
remotely serious)

extra-float-spacing: none | new-behavior

"none" would give the current behavior.  "new-behavior" would behave
something like this.  Suppose we have a line box L that would overrun
a float F.  Let E be the most distant ancestor of L that is not an
ancestor of F.  When shrinking L, leave an extra amount of space equal
to the space you would get if E established a new block formatting
context, plus the margin of E (subject to margin collapsing).  As
usual, if the line box can no longer fit, it gets pushed down.  I'm
being lazy here in saying how much space should actually be left --
the idea is all the margins and padding of E and its descendants
containing L, but with margin collapsing and other magic working as
usual.

This idea is probably quite half-baked, but this is a fairly
irritating problem when mixing left floats and lists, and it would be
nice if there were a solution.  Perhaps someone else has a better one
(maybe even one that already exists)?

Received on Sunday, 27 December 2009 00:31:09 UTC