Re: Issue 101 Resolution

On 22/10/2010 09:42, Alan Gresley wrote:
> Anton Prowse wrote:
>> On 21/10/2010 08:06, Alan Gresley wrote:
> [snip]
>>> So in dbaron's test for rule 3, the containing block of the left floated
>>> box is the aqua box and the containing block of the aqua box is the
>>> yellow box. So the change now reflects the concept of nearest
>>> block-level ancestor.
>>
>> I have no idea what you're getting at here.
>
> I simply stating that in dbaron' test, the left floated box containing
> block is the aqua box and not the yellow box.

Yes.  I don't understand why this is noteworthy.


> [snip]
>>>> New rule 3 text (I overcorrected for "outer edge"):
>>>> | The right outer edge of a left-floating box may not
>>>> | be to the right of the left outer edge of any
>>>> | right-floating box that is to the right of it and
>>>> | whose left outer edge is to the left of the
>>>> | left-floating box's containing block's right edge.
>>>> | Analogous rules hold for right-floating elements.
>>>>
>>>> New rule 7 text (slightly cleaner):
>>>> | A left-floating box that has another left-floating
>>>> | box to its left, where the latter box's right edge
>>>> | is to the right of the former box's containing
>>>> | block's left edge, may not have its right outer
>>>> | edge to the right of its containing block's right
>>>> | edge. (Loosely: a left float may not stick out at
>>>> | the right edge, unless it is already as far to the
>>>> | left as possible.) An analogous rule holds for
>>>> | right-floating elements.
>>>>
>>> Can the above parts that have "containing block's right edge" be changed
>>> to "containing block's right content edge".
>>>
>>> s/containing block's right edge/containing block's right content edge/
>>
>> No, no. The containing block doesn't have a "content edge"; it's a
>> rectangular region.
>
> If you say this, then you still do not understand what a containing
> block is.

With respect, given your proposal above and your use of the term 
throughout this post, it is /you/ who doesn't understand the definition 
of containing block.

> I'm only talking about the change to rule 3 at this moment.
> The containing block (rectangular region) is formed by the content edge.

Precisely.  The containing block is /established by/ the content edge of 
a CSS box.  It does not have a "content edge" itself.  It's a plain and 
simple rectangle.

> In 10.1 we have.
>
> | 2. For other elements, if the element's position is 'relative'
> | or 'static', the containing block is formed by the content edge
> | of the nearest block-level, table cell or inline-block ancestor
> | box.
>
> And referring to this later part of rule 3 with Tab's change.
>
>  >>> | right-floating box that is to the right of it and
>  >>> | whose left outer edge is to the left of the
>  >>> | left-floating box's containing block's right edge.
>
> The left-floating box's containing block's right edge could be it's
> right margin edge, right border edge, right padding edge or right
> content edge.

Could be _what's_ right margin/border/padding/content edge?  The 
containing block is formed by the content edge of a particular ancestor, 
as you just cited.


> One must narrow the viewport for the following test.
>
> Using your most recent test but with a right margin on the containing
> block of the left floating box (green).
>
> <div style="float:right; width:150px; height:50px; background:red;"></div>
> <div style="width: 250px; background: blue; margin-right: 1000px;">
> <div style="background: aqua;">width of containing block is this aqua
> box</div>
> <div style="float:left; width:350px; height:150px; background:lime;
> "></div>
> </div>
> <div style="background:orange;">text text text text</div>
>
> This right margin is rightly ignored by all modern browsers apart from IE7.

I'm not sure about "rightly"; I believe this behaviour is unspecified. 
The blue div with the large margin sticks out of the right hand side of 
the initial containing block.  Gecko (and I believe all modern browsers) 
choose not to provide scrolling to the extents of margin that sticks out 
the right hand side of the initial containing block yet they do choose 
to provide scrolling to the extents of border, though.  This is true 
even if overflow:scroll is explicitly specified on the root element.


> Using your most recent test but with a right padding on the containing
> block of the left floating box (green).
>
> <!DOCTYPE html>
> <div style="float:right; width:150px; height:50px; background:red;"></div>
> <div style="width: 250px; background: blue; padding-right: 300px;">
> <div style="background: aqua;">width of containing block is this aqua
> box</div>
> <div style="float:left; width:350px; height:150px; background:lime;
> "></div>
> </div>
> <div style="background:orange;">text text text text</div>
>
> The right floating box only drops when it reaches the content edge of
> the containing block of the left floating box (green).

The right floating box doesn't drop at all; it's the first thing in the 
source.  However, the green left float does drop when the right float 
enters the left float's containing block.  It's this behaviour that's 
being codified by Tab.

> This is why I had requested this.
>
> s/containing block's right edge/containing block's right content edge/

Yes, but that's because you've misunderstood the definition of 
containing block.


>>> <!DOCTYPE html>
>>> <div style="float: right; width: 400px; height: 100px; background:
>>> green;">Right</div>
>>> <div style="float: left; width: 80px; height: 80px; margin-right:-100px;
>>> border: 10px solid blue;">Left</div>
>>>
>>> Narrowing the viewport, Gecko and IE8 will allow the right floating box
>>> (green) to pass under the left floating box (blue border) and go into
>>> the hidden overflow. Opera, WebKit and IE9 shows the left floating box
>>> (blue border) dropping when the left outer edge of the right floating
>>> box passes the left content edge of the 'initial containing block'.
>>
>> The dropping is correct, right?
>
> I not sure. I will not say it is right or not right since it's not even
> mentioned in the spec.

Yes it is.  It's Rule 3 (in both its traditional and newly-proposed form).

>> This is simply Rule 3 in its traditional form (and of course in its
>> newly proposed form too, since it's backwards compatible).
>
> This newly propose form doesn't change it. The old form doesn't change
> it. It just how IE8 and Gecko always treated this case since this case
> is following rule 1. For them, the float does not exist.

And they are wrong (although at least the behaviour is consistent with 
their handling of text next to floats with non-positive margin area 
width as raised in [1,2]).  If Mozilla and MS want to sanction their 
behaviour, they need to petition the WG.  Ditto with the text issue 
(although rendering errors with that issue are more excusable since 
"next to a float" wasn't defined in 9.5 until very recently).


>> The containing block is only tangentially relevant.
>
> Not when we are dealing with rule 1. Let reverse the order of the float
> in the above test.
>
> <!DOCTYPE html>
> <div style="float: left; width: 100px; height: 100px;
> margin-right:-100px; background: blue;">Left</div>
> <div style="float: right; width: 380px; height: 80px; border: 10px solid
> green;">Right</div>
>
> Narrowing the viewport, Gecko, Opera 9.5, Safari 4 and IE8 will allow
> the right floating box (green border) to pass over the left floating box
> (blue) and go into the hidden overflow.

This is in contravention of Rule 3.  In my opinion, the implementors 
should fix this behaviour.

> This is any browser that observe rule 1 with right floating boxes.

Yes, browsers seem to implement Rule 1 correctly, in general.  I guess 
it's the easiest one to handle.

> The lone one out is IE9 beta which shows the right floating box dropping
> when the left outer edge of the right floating box passes the left
> content edge of the 'initial containing block'. I presume this is
> because rule 3 for some reason is being observed.

Yes.  Why do you feel that Rule 3 should be ignored?

>>> I believe that Gecko and IE8 behavior is correct since the left floating
>>> box (blue) right outer edge (margin edge) sit on the same vertical axis
>>> as it's left outer edge. This means the float takes
>>> up no horizontal space in it's containing block as the below test shows.
>>
>> Whether it has zero- or negative-width margin area is irrelevant.
>
> Yes it is. It is the same as saying whether zero width box is irrelevant.

I don't understand this comment.

>> The only thing that matters is the location of its right outer edge.
>> (See also the related discussion in [1,2] where we're dealing with
>> line boxes rather than right floats.)

> Anton, the right outer edge can have a negative width.

That sentence doesn't make sense. You mean the right /margin/ can have 
negative width?  Of course it can.  What's your point?


Anyhow, I don't see how *any* of this relates to my reply to Tab.

>> [1] http://lists.w3.org/Archives/Public/www-style/2010Aug/0182.html
>> [2] http://lists.w3.org/Archives/Public/www-style/2010Sep/0129.html

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

Received on Friday, 22 October 2010 17:13:05 UTC