Re: Issue 101 Resolution

On 09/10/2010 15:09, Alan Gresley wrote:
> Anton Prowse wrote:
>> On 08/10/2010 21:26, Anton Prowse wrote:
>>> 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:
>
>
> I agree but for different reasons. I see it as a set of rules that are
> one sided (the nature of floats), either left or right.
>
>
>>> 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.
>
>
> The horizontal overflow of a float from it's containing block is not
> clipped. That can only happen if the containing block has overflow:
> hidden. Is the overflow of this float ignored?
>
>
> <!DOCTYPE html>
> <div style="width:300px;border:5px solid blue;">
> <div style="float: left; width:400px; height:150px; background:
> lime;"></div>
> </div>
> <div style="background: orange;">This text flows around the float</div>

Hmm, you're right; the overflow is only ignored for certain rules.  For 
instance, it's ignored for Rule 3, but not ignored for Rule 2 (which is 
very similar to the line box "rule" that you illustrate above).

This does lead me to reassess whether current behaviour is justified, 
since I had plainly overestimated the impotence of float overflow in 
current browsers.  Whilst I feel that the theory of impotent overflow 
stands up to typographic scrutiny, I'm less inclined to petition for 
this change given that browsers don't follow that theory as closely as I 
thought they did.  As Tab noted, *any* change from current browser 
behaviour is likely to break pages, whether it be a change towards 
impotent overflow or a change towards supporting Rules 3 and 7 as 
currently specified (which Bert prefers).


> The reason that rule 3 is being ignored in some cases and in some
> browsers is due to rule 1.

How so? David's test case [3] doesn't involve Rule 1, for example.

> I believe that rule 3 was intended to deal
> with simple cases where both floats (left and right) interacted in the
> same containing block.

Certainly.

> Do you understand the intent of this test series [1]?

Indeed I do, but I don't see how it's relevant to Rules 3 and 7.  It 
essentially tests the strength of Rule 1.


>> I'm excepting /vertical/ overflow for floats here, obviously. The
>> non-impotence of vertical overflow of floats is a unique, integral and
>> justifiable part of float behaviour; it's also rather different from
>> horizontal overflow of floats and from any overflow of other boxes in
>> that these types of overflow are generally "accidental" (which is why
>> impotence is desirable) whereas vertical overflow of floats is
>> "expected".
>
>
> As above with your use of non-impotence. I see not much difference
> between horizontal overflow and horizontal overflow. The only difference
> is due to the direction of block progression. Overflow in ttb block
> progression typically overflows downwards.

I feel that there is a difference: accidental versus expected, as I 
said.  However, given that browsers do not ignore the horizontal 
overflow as universally as I thought they did, I'm less inclined to use 
this as justification for the current browser behaviour.


>> To make a case for non-impotence of horizontal overflow for floats,
>> you would need to present typographical justification for why the
>> second float should move downwards in this case...
>>
>> <!DOCTYPE html>
>> <div style="float:left; width:100px; height:100px;
>> background:yellow"></div>
>> <div style="margin-left:120px; width:150px; height:200px;
>> background:green">
>> <div style="float:left">supercalifragilisticexpialidocious</div>
>> </div>
>
>
> Should that not be this?
>
> <!DOCTYPE html>
> <div style="float:left; width:100px; height:100px;
> background:yellow"></div>
> <div style="margin-left:120px; width:150px; height:200px;
> background:green">
> <div style="float:right">supercalifragilisticexpialidocious</div>
> </div>

No.  I'm exploring Rule 7 here.

>> ...whilst the text doesn't move downwards in this one:
>>
>> <!DOCTYPE html>
>> <div style="float:left; width:100px; height:100px;
>> background:yellow"></div>
>> <div style="margin-left:120px; width:150px; height:200px;
>> background:green">
>> supercalifragilisticexpialidocious
>> </div>
>
>
> How could the text move downwards. The block with the text has it's
> margin-left sitting on the left edge of it's initial containing block,
> one which it shared with the float.

The text doesn't move downwards, that's the point.  The question is, why 
then (typographically speaking) should the /float/ move downwards in the 
first example as per Rule 7 as presently worded?  In fact it doesn't in 
current browsers, which I'm happy about; Bert thinks it should, but I 
don't see grounds for distinguishing the two examples.  Perhaps there 
/are/ no grounds for doing so, and the text should move down too in the 
first example.  Certainly, the current resolution to Issue 185[4] 
defines a line box to be next to a float even when the float doesn't 
intersect the line box's containing block; so does that mean we should 
also be applying the sentence "if a shortened line box is too small to 
contain any [...] content, then it is shifted downward until either it 
fits or there are no more floats present" from the current spec?

Whilst my support for current browser behaviour for Rule 3 is waning (it 
/does/ look inconsistent now that I compare it to current 
implementations of Rule 2 or equivalently your line box example), my 
support for the current behaviour concerning Rule 7 (and, by analogy, 
for modifying the sentence quoted above) still stands for now:

>>> 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.


> Anton, what do you think should happen here (view in Gecko).
> <http://css-class.com/test/temp/rule1and3-rtl.htm>
> Should the reverse happen in ltr (overlapping floats)?

That looks like another bug to me.  What I would have /expected/ Gecko 
to do would be to allow the green float to overlap the blue float when 
the blue float doesn't enter the green float's containing block 
(rightparent), but to then drop the green float once the viewport is 
narrow enough so that the blue float does enter.  (That's what Gecko 
does in ltr mode [with the float directions switched], which is more or 
less David's test case for Rule 3. Overflow is impotent – but only for 
certain rules such as Rule 3, it seems.)


Anyhow, to summarize, I'm now wavering on Rule 3 and am more inclined to 
agree with Bert that current behaviour should be regarded as buggy, but 
I share Tab's concern that changing this behaviour might be troublesome. 
  Bert's comment – that browsers have in any case been pretty slow at 
improving their float implementations – is a fair one though, and does 
go some way to countering Tab's argument IMO.  I remain supportive of 
current browser behaviour for Rule 7 since I think it honours the 
underlying intent of that rule.

[I'll reiterate that if the spec is going to change to sanction current 
browser then it needs to be worded in terms of "containing block" rather 
than "parent", as previously discussed on this thread.]


> 1. http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr.htm
> 2. http://lists.w3.org/Archives/Public/www-style/2008Mar/0423.html
   [3] http://dbaron.org/css/test/2009/float-outside-tests/rule-3-left
   [4] http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html

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

Received on Saturday, 9 October 2010 15:14:28 UTC