Re: Overflow and Margins

On Feb 3, 2008, at 2:06 AM, Ben Cotterell wrote:

> 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).

Bruno Fassino said that, and L. David Baron said it wouldn't work (it  
does seem to if I used padding on the wrapper, though, instead of  
margin).

> If the specification were changed to make overflow: scroll containers'
> contents implicitly always wrapped in shrink-to-fit containers,

Well, grow-to-fit, if that makes any difference. It is already sized  
to the minimum needed width (excluding the trailing margin, that is),  
if you consider non-wrapping, auto-width contents.

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

I wouldn't design it like that, but I can think of other reasons for  
having some blocks narrower than others within the overflowed block,  
and I assume your example is not tied to the behavior of centered text.

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

Perhaps I am not understanding you correctly. Doesn't the UA have to  
determine the width of something with width set to auto? Doesn't it  
use that in order to determine how wide to make the scroll pane  
within the scroll box (i.e., to determine how far the user can scroll  
right and left)? If I have non-breaking auto-width content that is  
wider than the 200px, then its width (plus its padding, border, and  
all margin other than right margin, apparently) is used to determine  
the size of the scroll pane. If it is smaller than 200px, then the  
corresponding properties of the 200px element are used.

>
>> 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?

You might as well ask why have margins at all? In this case, it is  
often easier to scroll all the way to the right than to scroll a few  
pixels from all the way to the right. The margin aids in readability  
when content is not all pressed together. The same problems happen  
when padding is used on the container, by the way. So whether the  
author uses padding on the container or margin on the container's  
contents, the intention of the author is very clear, and is not being  
met. You can really see the problem when you look at the example  
included with the mozilla bug (it is in a vertical context, using  
padding, but is the same problem) [1].

If the author wants to have margin inside the scroll box, why honor  
that for the left, but not the right? You could have said "But how  
often do people want to continue scrolling BACK TO THE LEFT 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.

I don't see it that way.  If an author doesn't want margin around the  
content area, they are always free to specify that it's contents  
should have none. If an author doesn't want padding around the  
content area, they are always free to specify that the container  
should have none. I still can't see any reason (other than following  
a flawed spec) why it is OK to include the trailing padding and  
border, but not the trailing margin, when determining the size of the  
extent box (what I have been calling the "scroll plane"). Or why the  
top and left margins are considered to always be part of the content  
area, but right and bottom margins sometimes are not.

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

Seriously? Create extra structures in the HTML in order to achieve  
the styling that is already reasonably specified in the CSS? There  
are so many reasons why this is not a reasonable solution, not to  
mention going against a central philosophy of CSS.


[1] https://bugzilla.mozilla.org/attachment.cgi?id=12403