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

Re: [CSS 2.1] [section 9.5 Floats] Empty floated element with a set width but height:0

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 08 Aug 2010 11:13:12 +0200
Message-ID: <4C5E7528.6030004@moonhenge.net>
To: www-style@w3.org
CC: "Tab Atkins Jr." <jackalmage@gmail.com>
Tab Atkins Jr. wrote:
> On Sat, Aug 7, 2010 at 3:21 AM, Anton Prowse <prowse@moonhenge.net> wrote:
>> Tab Atkins Jr. wrote:
>>> Some further information:
>>> We agree that a zero-height float (or a float whos bottom edge is
>>> incident with the top edge of a line box) doesn't force the line box
>>> out of the way in any browser.
>>> A further question concerns zero-height floats which appear in the
>>> middle of a line.  For example:
>>> <!DOCTYPE html>
>>> <div style="float:left; width:50px; height:5px; background:blue;"></div>
>>> <div style="float:left; clear:left; width:100px; height:0px;"></div>
>>> <span>foo</span>
>>> The first float definitely shoves the text over by 50px.  The question
>>> is whether the 0-height float should further push it or not.
>>> Chrome doesn't push it, but that's part of a general bug where Webkit
>>> doesn't take into account floats that don't intersect the top of the
>>> line box.  (Make the second float 5px hight and give it a background
>>> to see what I mean.)  So it's a wash, and tells us nothing.
>>> Firefox doesn't push the text.
>>> IE and Opera push the text.
>>> If I'm recalling correctly (doesn't look like the comment made it into
>>> the minutes today), Dbaron said he'd be willing to change the Firefox
>>> behavior here (but it may make his current implementation strategy
>>> slightly more difficult).
>> Again, this is about continuities.  What if the second float's margin
>> area height were negative?  I'd expect (insist, actually) that it be
>> ignored for the purposes of line box shortening.  Should it stop being
>> ignored at zero height, or at positive height?  Positive height seems
>> the more sensible to me.
> Are you talking about the case where the float is at the top of the
> line box, or in the middle?
> In the "top of line box" situation, it should be treated identically
> to any other positive-height float that happens to have a bottom
> margin edge incident with the top edge of the line box.
> In the "middle of line box" situation, several behaviors seem sensible
> to me.  We can make it not count when it's zero-height, not count when
> it's negative height, or just count all the time.

I don't see any basis for distinguishing the two cases.  That said,

> <!DOCTYPE html>
> <div style="width:200px;background:gray">
>     <span>text</span>
>     <span style="float:left;height:5px;width:50px;background:red"></span>
>     <span style="float:left;clear:left;height:5px;width:100px;background:green"></span>
> </div>
> IE8 can't cope with the idea of two floats stacked one atop the other
> next to the same line box.  Fx3.6 and Sf5 pretend the second float
> doesn't exist.  Op10.6 lets its IE6 roots show through and bizarrely
> sums the width of both floats together when calculating the line box
> shortening.

Opera 10.6 (whose bug can be avoided by putting the in-flow text after
the floats instead of before) seems to think that the only thing that
matters is the location of the bottom margin edge of a float.  In other
words, a line box is thought to be "next" to a float if and only if the
float's top margin edge lies above the bottom of the line box, and its
bottom margin edge lies below the top of the line box.  Hence, a "middle
of line box" float with a small-enough negative margin area height does
influence line box shortening.

Whilst I can't say this corner-case behaviour keeps me awake at night, 
it feels like an implementation artifact to me, rather than something
that's typographically desirable.

Anton Prowse
Received on Sunday, 8 August 2010 09:14:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:49 UTC