Re: Issue 101 Resolution

On 06/10/2010 21:36, Bert Bos wrote:
> On Wednesday 06 October 2010 01:48:17 Tab Atkins Jr. wrote:
>> This email is an attempt to resolve Issue 101
>> (http://wiki.csswg.org/spec/css2.1#issue-101)
>
>> Suggested Change
>> ================
>
> Why do you propose to change the spec? It's just an implementation bug,
> isn't it?

Well, the behaviour doesn't match the spec, sure.

However, I remain unconvinced that browsers' current behaviour is 
undesirable.  To me, it seems rather logical.  As I've mentioned a 
couple of times already, the issue here is containing blocks and overflow:

Firstly, browsers treat all floats as if their overflow from their 
containing block is clipped (ie ignored for layout purposes).  This is 
enough to "explain" the test cases for Rule 3, and some of the test 
cases for Rule 7.

This behaviour is reasonable because overflow is impotent in all other 
ways in CSS21, so it's anomalous that it isn't impotent for floats.

Secondly, browsers think that Rule 7 only applies when the presence of a 
previous left float causes the current left float to overflow its 
containing block more that it would if the previous float did not exist.

This behaviour is reasonable because Rule 7 only exists in the first 
place to make the new left float overflow as little as possible. If the 
previous left float isn't causing the new one to overflow more, then 
there's no reason at all to prevent the new left float from being on the 
same horizontal level as the old one, even though it's overflowing its 
containing block to the right.  To me, moving the new left float down is 
just silly; it overflows its containing block by exactly the same amount 
anyway.

> The bug is probably the result of an "optimization" that wasn't thought
> through correctly. It's not intrinsic to the model

Perhaps not.  Still, I don't get the impression that the model gave much 
thought to floats in different containing blocks anyway, so I don't much 
buy that argument.

> That is true even if the changed behavior would be better in some way.
> But, in fact, it isn't better. It is much worse. It makes no sense that
> the width of the parent influences whether the two floats overlap.
> Floats shouldn't overlap in the first place. And if the parent has such
> influence, why not the grandparent? It just makes no sense at all.

It's containing block we're interested in, not parent per se.  (Peter 
Moulder noted this too; the parent does not establish the containing 
block in some common cases, eg inline parent.)  I think Tab needs to 
reword his new text in terms of containing block, and then the seeming 
arbitrariness of "parent" goes away.

> Take this example. This is a little trick to center a green box, while
> there is already an orange box on the right. If there is not enough
> space for both, the green box is lowered.
>
>      <!doctype html public '-//W3C//DTD HTML 4.01//EN'>
>      <title>Test</title>
>      <style type="text/css">
>      .orange {width: 5em; height: 4em; background: orange; float: right}
>      .green {width: 5em; height: 3em; background: lime; float: left}
>      .centerwrapper {width: 5em; margin: auto}
>      </style>
>
>      <div class=orange></div>
>      <div class=centerwrapper>
>        <div class=green></div>
>      </div>
>
> (Try increasing the font size or narrowing the window until there is no
> room for green and orange side by side.) This works, both in the
> current spec and in Tab's proposed change. But in Tab's proposal only
> if the wrapper has the same width as the green box. In reality, it is
> easier to make a generic wrapper of width zero, and then the green box
> only needs to coordinate its own width and margins, as follows:
>
>      .centerwrapper {width: 0; margin: auto}
>      .green {width: 5em; margin-left: -2.5em;...}
>
> Under Tab's proposal, however, this creates overlap.

[Well, I'd hardly say that that was "easier" than your first example! 
 From a layout perspective it's generally wiser to be explicit with 
these "grids" (and hence make the parent the same dimension as the 
float) even if it's not visually necessary.]

Your second example results in overlap because the float entirely 
overflows its containing block.  I have no problem with this; I do feel 
that overflow should be impotent.

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

Received on Friday, 8 October 2010 19:27:04 UTC