W3C home > Mailing lists > Public > www-style@w3.org > March 2011

RE: [CSS21] Auto height of block with horizontal scrollbar

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>
Message-ID: <07349ECFC3608F48BC3B10459913E70B12CFD32B@TK5EX14MBXC132.redmond.corp.microsoft.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC