Re: padding lost in overflow

On 11/01/2014 10:25 PM, Robert O'Callahan wrote:
> On Sat, Jan 11, 2014 at 11:24 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> overflow:scroll is *not* just
>> "overflow:visible, but we don't show the overflow and instead you can
>> scroll to it"
>
>
> No, that's exactly what it is in Gecko/IE (and the spec).

This spec does not define what happens to the padding-box. It does not 
state anywhere that the padding-box should be clipped so Gecko/IE can 
not be said to follow the spec where what is in question is undefined.

>> So, the background is clearly laid out "as large as the contents",
>> because it's inside the scrollable area.
>
>
> No, it's actually "as large as the container", and under the scrollable
> area. In Ojan's example, set the background to an image instead of a solid
> color and this becomes a lot more obvious.

True. An image that has a background size of 100% by 100% is hidden by 
the width of the scroll bar (about 20px). Center is 50%+20px since it's 
the center of the border-box. It just makes 'background-origin: 
content-box' look rather odd.

>> It seems more logical to lay out the contents normally, as if you were
>> doing overflow:visible, then grow the content box to fully contain the
>> contents
>
>
> What exactly would it mean to "grow the content box to fully contain the
> contents"? I guess it would have to mean something like "determine the
> height of the content box as if the element was height:auto, even when it's
> not". Which would be weird since 'height' is defined to set the height of
> the content box.

Not all overflow boxes have to have a height or width. Most of the 
examples I have seen on the internet is when wide image are used. 
Wikipedia uses overflow for cityscape images [1]. Talking from a user 
perspective, I find myself having to look at the scroll-bar to know that 
I have scrolled fully to reveal all the image and speaking from an 
author perspective, I would overcome that by using a color that is 
different to the average color range of the image and use 
'background-origin: content-box' for the image.

>>, and wrap the padding box around that as normal.  The first
>> part is what we do already; it's really weird that the content box is
>> allowed to overflow the padding box.
>>
>
> No, the content box doesn't overflow the padding box in Gecko. In Ojan's
> example, or in fact any example where 'height' is not 'auto' (regardless of
> the value of 'overflow'), the content box and padding box do not depend on
> the contents of the element. The height of the content box is simply the
> value of 'height'. The children of the element may overflow the element's
> content and padding boxes.
 >
> It's your proposed change that's really weird :-). It would mean 'height'
> no longer sets the height of the content box, and the element's content-box
> and padding-box can overflow the element's border-box and margin-box.

Height already sets the height of the content box regardless of what is 
happening. The change is to show the full padding box instead of 
clipping it where it is located in overflow. The whole thing of overflow 
is the it separates the width of the border-box (plus the width of 
scroll-bar) from the padding box (or width and padding combined). 
Overflow of any value except visible only establish a containing block 
for positioned elements but unlike other parts of CSS, the width of 
block formatting context is wider than the containing block. That is 
what is weird. :-)

> I agree that the current behavior is confusing. I think the real problem is
> that the scrolled area includes the padding instead of just the scrolling
> element's content-box, which may be a historical accident. But I'm
> skeptical that your proposed change makes things overall more sane.
>
> Rob

Did you ever view how it worked in IE7?


1. http://en.wikipedia.org/wiki/Geneva#Cityscape



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Saturday, 11 January 2014 13:44:42 UTC