W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: Issue 101 Resolution

From: Alan Gresley <alan@css-class.com>
Date: Thu, 21 Oct 2010 17:06:33 +1100
Message-ID: <4CBFD869.2000204@css-class.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Anton Prowse <prowse@moonhenge.net>, www-style list <www-style@w3.org>, Peter Moulder <peter.moulder@monash.edu>
Tab Atkins Jr. wrote:
> On Wed, Oct 20, 2010 at 11:05 AM, Anton Prowse <prowse@moonhenge.net> wrote:
>> On 20/10/2010 18:05, Tab Atkins Jr. wrote:
>>> Based on feedback in this thread, I believe that the changes I'm
>>> proposing for Rules 3 and 7 are correct, except that they should be
>>> phrased in terms of containing blocks.
>>>
>>> Rule 3 Current Text:
>>> # 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.
>>> # Analogous rules hold for right-floating elements.
>>>
>>> Suggested Text:
>>> | 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 outer
>>> | edge. Analogous rules hold for right-floating elements.
>> s/right outer edge/right edge/
>>
>> So you're sanctioning the overlap behaviour shown by most browsers when
>> rendering the test case in [1].  Is there some typographical justification
>> for that behaviour, or is your decision purely pragmatic?
> 
> Pragmatic.  In the thread, you guys pointed out several browser bugs
> related to rule 3 violations, but they are inconsistent and clearly
> bugs (for example, FF in some cases does things "correctly" when you
> load a page with a certain size, but not if you resize a page to that
> size).  The one change I've made to rule 3 may not have great
> theoretical justification, but it's easy to talk about and everyone
> treats it consistently and interoperably.


I agree with Tab. This overflow of float behavior is at this point not 
in the spec and many test show some wild behavior. I do see this in 
the spec 10.1 (Definition of "containing block" ) point 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.


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.



>>> Suggested text:
>>> | 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 original left-floating 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.
>> s/original left-floating/former/
> 
> Good catch; that makes the text cleaner.
> 
> 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.
> 
> ~TJ


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/


BTW, I have only really looked at rule 3. I still considering this 
test for rule 3.


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

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.


<!DOCTYPE html>
<div style="border: 10px dashed red; background: yellow;
display:inline-block;">
  <div style="float: left; margin-right: -200px; width: 200px; height:
100px; background: blue;"></div>
</div>


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

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Thursday, 21 October 2010 06:07:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT