- 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