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

Re: Question about run-in and floats

From: Alan Gresley <alan@css-class.com>
Date: Thu, 21 Jan 2010 23:07:25 +1100
Message-ID: <4B58437D.8070201@css-class.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: www-style list <www-style@w3.org>
Boris Zbarsky wrote:
> On 1/15/10 2:24 AM, Alan Gresley wrote:
>> Interesting. Hard to test since I only have FF 3.6.5 (beta) which does
>> not support run-in. The following test case shows diverging behavior
>> between IE8, Opera 10 and Safari 4.0.4.
>> <http://css-class.com/test/css/visformatting/run-in-with-float-clear.htm>
>> I would expect the clearing element to clear the float.
> Why?

The reason why you would want an element to clear a float within a 
run-in box is because the float itself may have undeclared or intrinsic 
(images) height. I could not imagine using margin-top on such an element 
that you wanted placed below the float.

I myself see very little use of having a float within a run-in box 
anyway since simpler constructions could be coded by simple floating. 
Another reason that I see little use of having a float within a run-in 
box is due to this 9.2.3 of the spec.


# 1. If the run-in box contains a block box,
# the run-in box becomes a block box.

Since a float generates a block box, then the run-in element will also
be a block box.

>> IE8 and Opera 10.10 shows the same with the clearing element clearing
>> the float.
> IE8 and Opera 10.10 do not run in a run-in that contains a float.

I presume that is because both implementations are following the above 
mentioned spec.

> At 
> that point the behavior is clear: the following block needs to clear the 
> float.  But the behavior of not running in the run-in in this case is 
> not what was decided on the last time the working group discussed it, so 
> the question is what should happen given that the run-in _is_ supposed 
> to run-in.

i would say the current rendering seen in IE8 and Opera 10.10> If this 
didn't happen then 9.2.3 would have to be changed. Here is an updated 
test case.


Please note the test marked with an asterisk '*'. In IE8 with 'Time New 
Roman' as the font, resizing the text to smallest will allow the run-in 
box to sit beside the float instead of sitting above the float. This is 
because I have declared a width on the run-in box. When the width of 
this run-in box is smaller than the width of the text added to the width 
of the float, then the run-in box is forced above the float.

>> The clearing element does not clear the float in Safari 4.0.4
>> and shows missing content with the run-in element
> Oh, sure.  There's missing content all over the place in Safari's run-in 
> implementation.  Also all sorts of dynamic behavior bugs, and in the 
> shipping version a bug with run-ins not really becoming blocks if 
> followed by an inline.  Pretty much everything other than the very 
> simplest behavior (a run-in followed by a block runs in) is broken, and 
> even the simplest thing is broken if there happens to be a layout flush 
> between the run-in and the block.  It's basically not really worth it to 
> look at Safari's behavior here....

Agree totally. I would suggest to those working on WebKit to drop 
support for run-in until they can fix the missing content bugs.

> -Boris
> P.S.  Haven't tried IE8 on my testcases yet, but here's a fun one that 
> causes missing content (the string "header") in Opera:
>  <body>
>    <div style="display:run-in">
>      Run-in
>      <span>
>        <span style="display:table-cell">
>         <span style="position: absolute">header</span>
>        </span>
>      </span>
>    </div>
>    <div>A block</div>
>  </body>

I can see many test cases are needed. The above look interesting. Opera, 
like WebKit or even IE8 and Gecko have bugs with usual constructions and 
newer properties that are not in popular use. They being the table 
properties and run-in.

Alan http://css-class.com/
Received on Thursday, 21 January 2010 12:08:05 UTC

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