Re: padding lost in overflow

On Tue, Jan 14, 2014 at 8:47 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

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

Yes, background-attachment:local changes things. My point stands that
background-attachment:scroll (default) puts the background behind the
scrolled content, sized and positioned according to the container's
content, padding and border boxes as currently defined in the spec. The
testcase in my previous email clearly shows that even Blink is doing this.

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

What do you mean by "bounding rect"? Consider the following testcase:
<!DOCTYPE HTML>
<div style="overflow:scroll; width:200px; height:200px; padding:50px;">
  <div style="height:500px; width:150px; background:blue">
    <div style="height:1000px; width:100px; background:red;">
  </div>
</div>

If the "bounding rect" means the scrollable overflow area of the contents
(that's what we call it in Gecko, I hope you know what I mean), then the
padding would be placed below the bottom of the red DIV. That's not what
Blink does though. I think it places the padding below the bottom of the
blue DIV, so it's behaving more like I suggested. If you mean "union of the
margin-boxes of the direct children of the scrollable container", then
you're probably getting close to what Blink does, but that's not an obvious
definition.

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

So with your proposal the element has two kinds of content-box, the "as far
as the outside world and percentages on children are concerned", and
another one corresponding to where padding is placed? Then I really think
you should give them different names and we'd need to disambiguate all
existing references to "content-box".

> 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 see what you mean, but I hope you agree the current spec's approach has
an advantage of not requiring this TARDIS-like mental model :-).

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

I think the best way to achieve what you want is to not officially alter
the container element's content and padding boxes. Instead, just add extra
space to the scrollable area based on the computed padding of the container
element, defining carefully where it is added with a similar approach to
what I suggested before. That would address most of the problems I've
raised, but we'd still have the situation that APIs referring to the
content or padding boxes of the container element are going to be confusing
to authors, more so than if we stick to the hard line that Gecko, IE and
the spec are currently taking.

I think focusing on my previous email would help progress this discussion.
That example makes it crystal clear that if you put padding where you want
it to be, authors will have to think about the content and padding boxes of
the element being in two different places depending on how they're being
used (unless you want to try making drastic changes to the rendering of
existing content).

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w

Received on Monday, 13 January 2014 20:58:02 UTC