Re: Issue 101 Resolution

On 10/10/2010 17:58, Alan Gresley wrote:
> 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].

Yes.  Hence my use of "very similar" and not "equal".


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

I am referring to the inability of overflow to affect layout.  For 
example, inline-level content (such as text) which horizontally 
overflows its containing block does not influence in any way any box or 
text which it may visually overlap.  In-flow block-level content which 
vertically overflows its containing block does not influence the 
location of any subsequent box.  To my knowledge, only floats (as 
specified, and in practice in certain cases) have the ability to 
overflow and still influence layout; in other words, float overflow is 
not impotent.  I was pondering whether it ought to be.


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

Insofar as *any* test case involving one or more floats necessarily 
involves Rule 1, yes.  Clearly that's not the point of interest in 
David's test case, however.

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

Indeed, but that's not Rule 1; that's your being unclear as to whether 
it's negative right margin or overflow that we're seeing when the left 
float sticks out of the right-hand side of its containing block.  (You'd 
be forgiven for thinking that it might have been negative right margin; 
after all, the float is visually overlapping the right float which would 
be in contravention of Rule 3 if it were overflow that we were seeing.) 
  The fact is, however, that it *is* overflow, and hence Rule 3 is 
indeed being contravened.  That's the subject of this thread.


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

This appears to demonstrate the same thing as David's test case [3]. 
Rule 3 says that the right float should drop, but it's being ignored.

> Now returning to the test case,
> I am amazed to see that IE9 shows the floated right box dropping.

As per Rule 3.  Interesting.  Does IE9 also drop the the left float in [3]?


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

This lends more weight to the idea that contravention of Rule 3 is an 
implementation bug.  It's looking increasingly like we should keep Rule 
3 as specified (or move to the impotent float overflow model).


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

The Gecko and IE8 behaviour is clearly buggy.


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

Of course you *can* have float drop here if you choose to implement Rule 
7 as currently specified.  That's the point.


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

I see no relevance of that.


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

Yes, that's the test case that the author had in mind when drafting Rule 
7.  Unfortunately, the evidence suggests that the author didn't give 
thought to what happens when one of the floats participates in the same 
BFC but doesn't intersect the other float's containing block.  *That's 
what this thread is about*.  According to Rule 7 as currently worded, 
the float should drop in the example I gave.


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

I think you've misunderstood the discussion.  See above.


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

Yes.  My point is that its unclear what typographic grounds exist for 
distinguishing them for the purposes of deciding whether to drop the 
float/text based on the existence of float/text overflow when next to 
the first float.


> [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 don't think anything can be reliably concluded.  When layout changes 
on refresh it's symptomatic of a buggy implementation.  The fact that 
the float drops when the page is refreshed does however indicated that 
Gecko tries to obey Rule 3 when it's forced to think about it a bit 
harder.  Which lends yet more support for the idea that current browser 
behaviour for Rule 3 is merely a result of misimplementation and that 
the rule as currently specified should stand.


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

I don't see any particular importance of Rule 3 here.  Clearly all 
writing modes and directions need to be specced and implemented 
appropriately.


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

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

Received on Sunday, 10 October 2010 20:18:56 UTC