Re: Overflow and Margins

On Sat, Feb 02, 2008 at 03:03:32PM -0800, Brad Kemper wrote:
> On Feb 2, 2008, at 2:24 PM, Bruno Fassino wrote:
> >
> >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.
> 
> Interesting. Maybe the definition of "containing block'" should be  
> changed then. It seems to me that once scrollbars are produced, there  
> are two boxes instead of one: the box that contains the parent's  
> border, margin, and scrollbars, and the box inside that which  
> contains  the parent's padding and contents.

Overflow: scroll is no different to overflow: visible or overflow:
hidden. You calculate the widths as specified (a function of containing
block width, styled widths, in some cases preferred widths, etc.) and
then if when all is said and done they overflow the overflow property
tells you what to do about it.

It's better to think of it as a kind of rendering effect, not as part of
layout at all (apart from the block-formatting-context-generating
side-effects).

Some browsers allow the value of overflow to have an effect on preferred
width calculations in some circumstances, but I don't think that's
right.

> This inner box grows as  large as it needs to in order to contain its
> contents, and is  revealed when scrolling. So, shouldn't this inner
> box be the new  containing block, and shouldn't it also grow to
> contain the right  margin, just as it grew to contain the other
> margins and the content?

But what would its width be?

You need a containing block width to work out all the other widths.

Suppose I have something like this:

    <div style="width: 200px; overflow: scroll">
        <div style="width: 400px"></div>
        <div style="width: auto" id="foo"></div>
    </div>

How wide should div#foo be? Does the preceding div cause the container
to grow to 400px, making #foo's used width 400px?

You can get that effect already by wrapping the contents in a
shrink-to-fit container (as I think you said).

If the specification were changed to make overflow: scroll containers'
contents implicitly always wrapped in shrink-to-fit containers, which I
think is what you're effectively suggesting, that would take away
flexibility.

Take the example above. #foo might contain only a couple of words and
have text-align: center set on it. The author would probably prefer to
have that text centered within the visible 200px of the container than
have to scroll right to see half of it.

In this case she could set width on #foo to 200px but of course in other
cases the container itself will be width: auto, and so the exact value
to set #foo's width to wouldn't be known.

> I would propose that something change to allow that to happen. It
> seems like it would have a rather mild effect on existing designs,
> while making the effect of margins more predictable.
> 
> >
> >[1] http://www.w3.org/TR/CSS21/visudet.html#blockwidth

But how often do people want to continue scrolling to the side just to
see a margin?

I think this is going to be very difficult to achieve with a spec
change, because there are two different requirements. Some blocks
occasionally want to fit into the "extent box" (the bounding box that
includes overflowing children), others into the real content area.
There's no one-size-fits-all solution.

Better for authors to create extra shrink-to-fit wrappers where they
need them to say what they want.

Received on Sunday, 3 February 2008 10:06:31 UTC