Test and demo pages
[CSS21] Nested floats and zero-height margin box
in particular the objection from Øyvind Stenhaug
First of all, the outermost floats here are all auto-width, in which
case "CSS 2.1 does not define the exact algorithm" for finding preferred
width and preferred minimum width.
Second of all, what does it mean for a right-floating box to be "next
to" a left-floating box? This doesn't seem to be properly defined.
Perhaps it should be similar to the case of lineboxes "next to" floats,
where floats with zero outer height are not supposed to shorten
lineboxes. Then, for e.g. float-non-replaced-width-014 it would be
perfectly fine to put #floated-left-child in the top left and
#floated-right-child "below" it - #floated-right-child would still be
"as high as possible".
Excerpts of current spec
The right outer edge of a left-floating box may not be
to the right of the left outer edge of any right-floating box
that is next to it.
A left-floating box must be put as far to the left as possible, a right-
floating box as far to the right as possible.
9.5.1 Positioning the float
If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.
Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of 'margin-left', 'border-left-width', 'padding-left', 'padding-right', 'border-right-width', 'margin-right', and the widths of any relevant scroll bars.
Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).
10.3.5 Floating, non-replaced elements
The CSS2.1 spec should indicate expected result for the 4 tests, in particular
I propose closing this bug as resolved-wontfix, as explained in http://lists.w3.org/Archives/Public/www-style/2012May/0707.html