RE: Overflow and Margins

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. 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. 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 19:09:29 UTC