- From: Arron Eicholz <Arron.Eicholz@microsoft.com>
- Date: Mon, 14 Mar 2011 20:30:35 +0000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, Øyvind Stenhaug <oyvinds@opera.com>
- CC: "www-style@w3.org" <www-style@w3.org>
On Friday, August 27, 2010 9:30 AM Boris Zbarsky wrote:
> On 8/27/10 9:02 AM, Øyvind Stenhaug wrote:
> > Well, if they increment the padding then they only do so for auto
> > height, not when the height of the outer div is explicitly set to 100px.
>
> Ah, ok. That's interesting.... For an auto-height div, putting the scrollbar into
> the padding is clearly the right behavior from the standpoint of authors.
> Otherwise any overflow:auto block with horizontal overflow and auto height
> would also be forced to have vertical overflow, right? So I think we should
> make sure that the spec handles that case well.
>
> >> It's not clear from section 11.1.1. whether the scrollbar insertion
> >> changes the used padding value or whether the scrollbar is supposed
> >> to "overflow" the padding, and if so in which direction. I would not
> >> expect it to overflow out, since that would make it overlap other
> >> content, so the options are either that the used padding is increased
> >> or the used width/height is decreased, right? Or I guess that the
> >> used margin is increased...
> >
> > Or the scrollbar is just painted on top of everything else, so that
> > its end edge equals the end edge of the padding area ("overflowing"
> inwards).
>
> That's the "used height/width is decreased" case, I think. At least that's the
> way I was thinking of it.
>
> > I've been wondering the same thing. I'm not sure why the text talks
> > about modifying the dimensions of "the containing block" (block? blocks?
> > as you mention further down, there isn't just one) and not just the
> > used width/height.
> > (<http://lists.w3.org/Archives/Public/www-style/2008Jan/0259.html>)
>
> I have no idea. :)
>
> > Well, in this case the computed value of 'height' should be 'auto' per
> > 10.5. My Safari/Firefox versions aren't as recent but they both seem
> > to honor that part (as does Opera).
>
> Oh, good catch. So the width differences are still relevant, but the heights
> being about half was a complete accident. And for width, the only case that
> was different was Opera's handling of the positioned block vs the other two
> engines' handling.
>
> > Yeah, I guess there are some bugs in the more general behavior, I just
> > focused on one case which seemed to be consistent.
>
> Yeah, ok. Let's stay on that one; as I said above, I think the consistent
> behavior is needed to make overflow:auto make sense.
>
Thank you for your feedback. The CSSWG resolved not to make changes to the CSS 2.1 specification[1]. We will be reevaluating this issue for errata and future versions of CSS.
Please respond before 18 March, 2011 if you do not accept the current resolution.
[1] http://w3.org/TR/CSS
Received on Monday, 14 March 2011 20:31:31 UTC