Re: padding lost in overflow

On Sat, Jan 11, 2014 at 3:25 AM, Robert O'Callahan <robert@ocallahan.org> 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).
>
>> 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.

Yup, I did this.  Under the default background-attachment, yes, the
background doesn't move.  Under "local", though, the background is as
large as the content.

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

Set the content box to be size of the bounding rect around the contents.

>> , 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'),

Sorry, by "what we do already", I meant "when height isn't constrained".

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

'height' still sets the geometric height of the context box, as far as
the outside world (and percentages on children) is concerned.
'height' has *never* constrained the contents when overflow space is
available.

> and the element's content-box and
> padding-box can overflow the element's border-box and margin-box.

Kinda sorta, not really.  They expand in the separate overflow space
that the 'overflow' property gives you access to.  They don't overflow
the border box *in the same space that the border box exists in*.
It's really that there's simple *more space* inside the border box
than would be assumed by looking at the outside dimensions.

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

My proposed change allows authors to put space at all edges of their
scrolling container using the standard mechanism of padding that
they're already used to.  Right now, they can only do so on the start
edges.  WebKit/Blink already allow this on the block-end edge as well,
just not the inline-end edge.

~TJ

Received on Monday, 13 January 2014 19:48:24 UTC