Re: [CSS21] Floating - who's right?

On 05/02/2011 02:08, fantasai wrote:
> On 02/04/2011 04:22 PM, Васил Рангелов wrote:
>> Hello CSSWG.
>>
>> I recently found something resembling a bug related to floats... but the
>> thing is two implementations do it one way, and two others do it another
>> way, so I don't know who's right and who's not. I hope that if I bring
>> the issue here, implementers would be able to resolve who's to fix what.
>>
>> The problem is that a relatively positioned box with a clear inside it
>> turns out on top of a statically positioned left floated box preceding
>> it.
>> Or at least that's what the latest public builds of Gecko (Firefox 4b12)
>> and WebKit (Crhome 9.0.597.84 and Safari 5.0.3) do. Here's a reduced
>> test case:
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>> <html xmlns="http://www.w3.org/1999/xhtml">
>> <head>
>> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
>> <title>TEST</title>
>> <style type="text/css">
>> .floated {float:left;}
>> .positioned {position:relative;}
>> .cleared {clear:both;}
>> </style>
>> </head>
>> <body>
>> <div class="floated">
>> <a href="#">click me if you can</a>
>> </div>
>> <div class="positioned">
>> <div class="cleared"></div>
>> </div>
>> </body>
>> </html>
>>
>> In the above mentioned browsers, the link is not clickable because of
>> this.
>
> Try giving the positioned element a border or a background, and you can
> see what's happening. A relatively-positioned element is rendered above
> any non-positioned elements, so it's placed over the float. The reason
> the link is clickable in Opera is because it lets clicks pass through
> a transparent background. Give the positioned div a background, and it
> won't be clickable anymore.
>
> CSS2.1 doesn't define click behaviors, so there's nothing there that says
> whether one behavior is right or wrong. But Tantek is working on defining
> click behaviors in the CSS3 UI spec, so hopefully he will consider this
> testcase.
>
>> Personally, I find the IE/Opera way more intuitive. I've found several
>> workarounds to make Gecko/WebKit behave like them (e.g. surround the
>> floated div with another div that is to match the position of the
>> positioned div, whether that means settings both to relative or static),
>> but I still never figured why this occurs and what the specification
>> requires. I was unable to find anything about that, though then again,
>> maybe I haven't looked hard enough.
>
> Try giving the float position: relative; z-index: 1. That will raise it
> above the relpos'd element.

Boris and fantasai are both correct, and fantasai gives a useful 
solution to the original problem.

However, the issue of interest to Васил, I believe, is why 
div.positioned has positive height, and hence is able to completely 
overlap the float and hence prevent mouse interaction with its contents 
in some browsers:

>>  the positioned element appears to have a height equal to the one of  the floated element.

The reason is quite simple: div.positioned "starts" at the top of the 
content area of body, since the float is out of flow and doesn't 
influence the location of div.positioned.  Hence the float and 
div.positioned intersect.  (This is very typical of floats and 
surrounding in-flow elements.)  Now, div.cleared is empty and has zero 
height.  If you remove the clear:left, its parent div.positioned has 
zero height. But with clear:left, div.cleared sits flush with the bottom 
of the float, "forcing" div.positioned to have positive height equal to 
the height of the float.  (The thing that Васил might have been confused 
about is that div.position doesn't get "dragged down" with div.cleared; 
its top remains at the top of the content area of body.  The situation 
would be quite different if it were div.positioned which had clear:left 
rather than its child.)

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Saturday, 5 February 2011 12:43:04 UTC