Re: Overflow and Margins

On Feb 3, 2008, at 11:09 AM, Alan Gresley wrote:

>
> Brad Kemper wrote:
>
>> On Feb 2, 2008, at 3:53 PM, Bruno Fassino wrote:
>
>>> But I see what you consider 'desirable'. Now it can probably be
>>> obtained with an extra (shrink-to-fit) wrapper around the content,
>>> inside the scrolling box.
>>
>> OK, so I may not have used the right words, but you understand what I
>> mean. I'm sure you can also see why it would be undesirable for an
>> author to have to insert an extra div, just in order to get the
>> specified margin to actually do the expected thing that margins
>> normally do (add space between an edge and the corresponding padding
>> edge of its parent block).
>
>
> I agree with Brad somewhat.

Thank you.

> I believe that the expected behavior should show the padding of the  
> overflow parent element completely but the value of one margin (the  
> right margin with ltr text) must be ignored. A use case is where  
> the inner box has a border and surrounding it is an overflow box  
> with a background. I wouldn't want the right border of the inner  
> box sitting up against the right edge of the overflow box.

Exactly. But this is also a reason to not ignore the margin too.  
Padding and margins are BOTH used by authors to keep the inner boxes  
from sitting up against the edges of their parent. For instance,  
imagine a box that contains several pictures that should all be  
equally spaced from each other and from the inner edges of the parent  
box, and the box has a max width but can accommodate 2 or 3 pictures  
across before scrolling (overflow:auto). I don't need to specify  
padding on the parent box; I can just say that a picture should have  
10px of margin around it. The margins collapse against each other for  
the pictures, and also space the pictures an equal distance from the  
edge of the box. But this nice margin disappears on the right if the  
box ever has to draw a horizontal scrollbar.

In any event, the same behavior occurs whether it is padding on the  
parent or margin on the children.

The margin behavior makes even less sense when you wrap the whole  
page in in CENTER tags. Basing the suppression of a particular margin  
on the reading direction doesn't make much sense if the blocks are  
center aligned (or even when the text is center or right aligned). In  
Safari 3, wrapping the page in CENTER tags has the effect of also  
suppressing the effect of the left margin.

> I would like to see some of the background to the right. Adding  
> another div to achieve this is not something an author should  
> expect to do.
>
>
> Bruno Fassino" <fassino@gmail.com>
>
>> Brad Kemper wrote:
>>> Isn't it a bit odd that of one block is wider than its parent, and
>>> the parent is set to "overflow:scroll", that the margins of
>>> the child are shown on the top, bottom, and left, but not on the
>>> right? Is that the way it is supposed to be?
>>
>> I guess this is because the "over-constrained" case of 10.3.3 [1]  
>> applies to
>> the child, so (when direction is ltr) the specified value of  
>> 'margin-right'
>> is ignored, and to satisfy the equality its used value must become a
>> negative value, but this has no effect on the rendering.
>>
>>
>> --
>> Bruno Fassino http://www.brunildo.org/test
>
>
> So what should actually happen in an "over-constrained" case. In  
> 11.1 [2] it says:
>
> |Whenever overflow occurs, the 'overflow' property specifies
> |whether a box is clipped to its padding edge, and if so,
> |whether a scrolling mechanism is provided to access any
> |clipped out content.
>
> There is no further mentioned on this page about the padding edge.  
> So does the containing block established by the overflow box begin  
> at it padding edge or content edge? I do think that this should be  
> defined.
>
> In the "over-constrained" cases like Brad's example, should and  
> overflow box with a width as a length be treated the same as an  
> overflow with width auto?
>
> <div style="border:1px solid; overflow-x:scroll;">
> <div style="height:5em; margin:.5em; width:200%;"></div>
> </div>
>
> <div style="width:400px;border:1px solid; overflow-x:scroll;">
> <div style="height:5em; margin:.5em; width:200%;"></div>
> </div>
>
> All browsers seem to agree on the width of the overflow box and the  
> width (padding edge) of the inner element regardless of if the  
> overflow box has a width which is length or auto. I see this as  
> correct. Only Gecko 1.8~1.9, Safari 3 (don't have a mac), Opera 9.5  
> and IE7 will actually render overflow-x:scroll properly. Gecko 1.7,  
> Opera 9.25 and IE6 render as of overflow-x was had a value of visible.
>
> Gecko 1.8~1.9, Safari 3 and Opera 9.5 will ignore the margin-right  
> of the descendant element in the overflow box in most cases. There  
> is a clear difference though if the overflow box has padding. Gecko  
> 1.8 will keep the padding-right of the overflow box where Safari 3  
> and Gecko 1.9 will either drop the padding-right of the overflow  
> box or the margin-right of the descendant element has a negative  
> value equaling the padding-right of the overflow box. Can anyone  
> clarify this? Opera 9.5 shows no "over-constrained" condition and  
> lengthen the scrollable box and on top that add a mysterious width.
>
> One lot of test cases is for an overflow box with width of auto:
>
> http://css-class.com/test/css/viseffects/overflow-auto-with-inner- 
> box.htm
>
> The equality values are arrived at when the overflow box is  
> narrowed to 400px. The other lot of test cases is for an overflow  
> box with width of length 400px:
>
> http://css-class.com/test/css/viseffects/overflow-length-with-inner- 
> box.htm
>
>
> Gecko 1.8 diverges from Gecko 1.9 and Safari 3 with the width of  
> the scrollable box from example 3a in each test case. This is where  
> padding is introduced on the overflow box. In  example 3c of each  
> test case i am not sure if the end of the equality line (?) for  
> Gecko 1.9 and Safari 3 should be.
>
> 'margin-right' 25px ~ 0px = 675px) + padding-right' 50px ~ 0px.
>
> or
>
> 'margin-right' 25px ~ -50px = 675px) + padding-right' 50px.
>
>
> In no part of 10.3.3 does it mentioned if padding-right is also  
> ignored so all I can equate from this is that the last case stands  
> true. So 'margin-right' for the descendant element is -50px. Where  
> it says in 11.1 "whether a box is clipped to its padding edge" is  
> this the type of case it referring to? If so then shouldn't  
> something be stated about "over-constrained" cases where the  
> descendant box is clipped at the "padding right edge" for ltr text  
> and the other edges at the content edge. This is taking that Gecko  
> 1.9 and Safari 3 shows correct rendering. If Gecko 1.8 is correct  
> then there should be mention somewhere about clipping occurring at  
> the content edge (containing block).
>
> [1] http://www.w3.org/TR/CSS21/visudet.html#blockwidth
> [2] http://www.w3.org/TR/CSS21/visufx.html#overflow-clipping
>
>
> Alan
>
> http://css-class.com/
>
>

Received on Sunday, 3 February 2008 22:01:09 UTC