Re: Issue 101 Resolution

Anton Prowse wrote:
> On 09/10/2010 15:09, Alan Gresley wrote:
>> Anton Prowse wrote:
>>> On 08/10/2010 21:26, Anton Prowse wrote:
[snip]
>> 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).


Rule 2 isn't happening here, this is [5].

   | Since a float is not in the flow, non-positioned block boxes
   | created before and after the float box flow vertically as if
   | the float did not exist. However, line boxes created next to
   | the float are shortened to make room for the margin box of
   | the float.


> This does lead me to reassess whether current behaviour is justified, 
> since I had plainly overestimated the impotence of float overflow in 
> current browsers.


Can you please clarify what you mean by impotence? Are you meaning 
importance instead or rather the definition of impotence (ie. utterly 
unable to do something or obsolete, without restraint)?


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


I don't understand what change you are talking about since I don't 
follow your usage of the word impotent.


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


There was a major change in browser behavior from 2008 to about 2009. 
All browsers changed to follow Gecko 1.7~1.8 behavior. It was this 
type of behavior which to my memory Opera 9.5, IE8 beta and Safari 4 
followed.


<!DOCTYPE html>
<html style="background: silver;">
  <body style="background: white;">
   <div style="float: right; width:4400px; height:150px; background: 
lime;"></div>
   text
   <div style="float: right; width:400px; margin-left: 4000px; 
height:150px; background: lime;"></div>
  </body>
<html>



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


Yes it does. The outer right edge of the right floated box is sitting 
on the right edge of it's containing block (the yellow box). The outer 
left edge of the left floated box is sitting on the left edge of it's 
containing block (the aqua box). This is why I queried the used value 
of the margin-right of the left floated box since I have never seen 
such overlap of floats in this context.


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


True, that is due to David Hyatt not wanting to scroll. The test was 
first set up in a container that had overflow: auto but was based on 
this behavior (the negative margin-right on the left floated box was 
is to avoid the IE hasLayout bug).


<!DOCTYPE html>
<div style="float: left; margin-right: -200px; width: 200px; height: 
100px; background: blue;"></div>
<div style="float: right; margin-left: 250px; width: 400px; height: 
100px; background: green;"></div>


Narrowing the viewport in IE7, Safari 3 and Opera 9.26 would cause the 
content to overflow to the right but could be scrolled too. In Gecko 
though, the floated right box overflowed to the left and becomes 
hidden. The same as Opera 9.5, WebKit 4 and IE8. Now returning to the 
test case, I am amazed to see that IE9 shows the floated right box 
dropping. Reversing the float order shows more non-interoperability.


<!DOCTYPE html>
<div style="float: right; margin-left: 250px; width: 400px; height: 
100px; background: green;"></div>
<div style="float: left; margin-right: -200px; width: 200px; height: 
100px; background: blue;"></div>


Narrowing the viewport in Gecko (I presume all versions) and IE8 shows 
the floats overlapping. WebKit (Safari 5), Opera 10.62 and IE9 shows 
the floated right box dropping.


So depending on the source order, rule 3 is observed or ignored.


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


Pass, current (and possibly future) browser behavior confuses me. 
Carrying on the same test as above but in reverse we have this (the 
text just helps us to see the intimal containing block which is the 
body element).


<!DOCTYPE html>
<div style="float: right; margin-left: -200px; width: 200px; height: 
100px; background: green;"></div>
<div style="float: left; margin-right: 250px; width: 400px; height: 
100px; background: blue;"></div>
text
<style>
html {background: silver;}
body {background: white;}
</style>


Narrowing the viewport in Gecko, WebKit (Safari 5), Opera 10.62 and 
IE8, the floated left box overflows to the right and produces a 
horizontal scrollbar. IE9 though shows the floated right box dropping.


<!DOCTYPE html>
<div style="float: left; margin-right: 250px; width: 400px; height: 
100px; background: blue;"></div>
<div style="float: right; margin-left: -200px; width: 200px; height: 
100px; background: green;"></div>
text
<style>
html {background: silver;}
body {background: white;}
</style>



Narrowing the viewport in WebKit (Safari 5), Opera 10.62 and IE9 shows 
the floated right box dropping. Gecko (I presume all versions) and IE8 
shows the floated right box not dropping but being pushed out of the 
viewport to the right. I haven't figured out Gecko and IE8 behavior 
yet with this test.


>>> 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?
[snip]
> No.  I'm exploring Rule 7 here.


You can not have float drop here. This is since the containing block 
_which is in normal flow_ has it's left border edge to the left of the 
outer right edge of the first floated left box. This is in the spec 
(see also above concerning inline content and flow) here [5].


   | Since a float is not in the flow, non-positioned block boxes
   | created before and after the float box flow vertically as if
   | the float did not exist.


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


This is not what rule 7 is about. It is saying that this should happen,


#--- CB ---#
|x=====x   |
|x     x   |
|x     x   |
|x=====x   |
|x=====x   |
|x     x   |
|x     x   |
|x=====x   |


instead of this,


#--- CB ---#
|x=====xx==|==x
|x     xx  |  x
|x     xx  |  x
|x=====xx==|==x
|          |


unless the later float it is already as far to the left as possible in 
it's containing block.


#--- CB ---#
|x=========|==x
|x         |  x
|x         |  x
|x=========|==x
|          |



> Perhaps there 
> /are/ no grounds for doing so, and the text should move down too in the 
> first example.


No reason to do so, see above.


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


No, the same as rule 7.


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


Rule 2 and my non-positioned box example (with inline content) are 
different. Rule 2 is interaction between one floated box and other 
floated boxes that occur earlier in the source.



[snip]
>> 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.)


Did you happen to see my second response to Bert [6] and what happens 
after refreshing (see rule1and3-rtl above). This test has Gecko 
computations going all wrong. For me both floats are honoring rule 1 
in a highly constrained situation and and rule 7 is more important 
then rule 3 in understanding it.


I will mention that rule 3 has an exception that none of the other 
rules have. All other rules are one sided where rule 3 has something 
left taking an interest in what is right. The reason why this 
important is that CSS2.1 rules of floats are all about TTB block 
progression and LTR inline progression (bias to top and left). This 
has to be fined tuned since the mirror computations must happen for 
RTL inline progression and it must also work when floats interact with 
vertical writing mode. Floats again can overlap or overflow strangely.


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


Agree with it being worded in terms of "containing block".


>> 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
5. <http://www.w3.org/TR/CSS21/visuren.html#floats>
6. <http://lists.w3.org/Archives/Public/www-style/2010Oct/0083.html>



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Sunday, 10 October 2010 15:58:59 UTC