Ingo Chao wrote:
Hi, while I was zooming the text-size in FF, I saw that
one line of text partly overlaps the red float.
http://www.satzansatz.de/cssd/tmp/lineinfloat.html
I have the feeling that the line box may not overlap the float. Or
is floating meant as the upper left (0,0) corner of the line box to
be floated? Only parts of the line box overlap.
So, when FF and Safari agree with overlapping the float, is this a
bug? Or is it expected behavior? And if so, why? What do you think?
I think this is undefined in the spec.
As you say, it is Rule 5 in the float spec [1] that controls how high
the outer top of the left floated box is. If you remove the bottom
margin from your floats (which confuses the issue visually), this
means the top of the left float will be precisely 4.5em from the top
of the containing block. You'll be able to see that in FF and
Safari, the overlap is precisely one-half of a line in the flowed
text paragraph at most text sizes (rounding prevents exact alignment
in some cases, but you can still see the basic problem).
So what is supposed to happen to that over-lapped line box? The only
place I could find in the spec that described the behavior between
floats and inline boxes [2] had this to say:
"... Any content in the current line before a floated box is reflowed
in the first available line on the other side of the float. In other
words, if inline boxes are placed on the line before a left float is
encountered that fits in the remaining line box space, the left float
is placed on that line, aligned with the top of the line box, and
then the inline boxes already on the line are moved accordingly to
the right of the float (the right being the other side of the left
float) and vice versa for rtl and right floats."
This language is very unclear. To me, it contemplates that the tops
of any floats will always correspond with the tops of any encountered
line boxes, and simply doesn't address the case presented here in
which the top of the float is between the tops of content line boxes.
The left float in this instance cannot be "placed on that line,
aligned with the top of the line box" because the vertical position
of the float has already been determined in reference to a different
line box (i.e. the line box generated by the right floats). Moving
the float as this paragraph describes would cause the floated box to
move too high.
Ideally, of course, one would hope that the UA would determine that
the entire inline box of the text does not fit, and would reflow that
line of content so it does not overlap. However, nothing I can find
in the spec actually requires that behavior, and I'm guessing the
Gecko and Safari algorithms simplify by only calculating the top of
each of the two boxes. Since the float top was below the inline box
top, my speculation is that those browsers simply stop there and do
not reflow that line.
Can you leave your sample page up a for a little while? This seems
like something to raise with the CSS WG, both for CSS 2.1 and the
CSS3 box module, and with your permission, I'll submit your page to
the WWW-Style mailing list. Meanwhile, Gecko and Safari are clearly
not exhibiting optimum behavior, so submitting this to Bugzilla and
Apple would also be appropriate, if you would like to do that.
[1] <http://www.w3.org/TR/CSS21/visuren.html#float-position>
[2] <http://www.w3.org/TR/CSS21/visuren.html#floats>
--
-Adam Kuehn
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
