- From: Thomas Rosenau <rosenau@seitenbau.com>
- Date: Tue, 28 Jan 2014 10:36:33 +0100 (CET)
- To: Gérard Talbot <www-style@gtalbot.org>
- Cc: www-style@w3.org
Hello Gérard, thanks for the clarification. I realized that I accidentally didn't reply to the mailing list. Hope it is ok to share the message below. > CSS width is to be substracted from the width of scrollbar even though > the scrollbar is located between padding box and border box. So, content > area is shrunk of "xxx" (from 9 "x" to 6 "x" in your ascii example) Well, is it really the content area or just the containing block formed by that element? When using { background-clip: content-box; } it can be seen that the content area is apparently not affected. (cf. http://jsfiddle.net/LNMZU/) Now, I found that the fundamental error I made was the assumption that a box's text content would take the whole content width. However, this is not the case, as can be seen from http://www.w3.org/TR/CSS2/visuren.html#anonymous-block-level So my current conjecture is that the following figure should be correct: +-------------------------+-+ | xxxxxx### |^| | xxxxxx### |~| | xxxxxx### | | | xxxxxx### | | | xxxxxx### | | | xxxxxx### |_| | xxxxxx### |v| +-------------------------+-+ | padding | width | padding | | | width-scrollbarWidth where xx=content and x#=content area. Again, this is because the text content forms an anonymous block and thus is constrained by the containing block. In other words: the element's containing block does not coincide with the content area. This feels a bit weird but it's the way the specs work. I think we agree that computedStyle.width should not be influenced by scrollbars. Best regards, Thomas ----- Ursprüngliche Mail ----- > Von: "Gérard Talbot" <www-style@gtalbot.org> > An: "Thomas Rosenau" <rosenau@seitenbau.com> > Gesendet: Montag, 27. Januar 2014 16:38:37 > Betreff: Re: [css3-box] How do scrollbars affect width calculation? > > Le 2014-01-27 04:32, Thomas Rosenau a écrit : > >> We already have several CSS 2.1 tests on this particular issue: > > > > None of these cover the question how the content area is influenced. > > Hello Thomas, > > I merely replied to the "how so" question I saw. Getting computed style > width of the element with a scrollbar should have returned 20px and not > 5px or 3px in the example I read. > > > > > I made a jsFiddle to illustrate the issue further: > > http://jsfiddle.net/9pAcp/2/ > > > This is a much more elaborated example...interesting design. > > clientWidth is very specific and must not be mixed up with css width. > > I have this demo: > http://www.gtalbot.org/BugzillaSection/DocumentAllDHTMLproperties.html > > > You'll note how the content area's width (text wrapping) equals > > cssWidth-scrollbarWidth, > > Yes I see this. The content area is narrower. And this is what the spec > says too. > > i.e. what I observe is this: > > > > +-------------------------+-+ > > | xxxxxx |^| > > | xxxxxx |~| > > | xxxxxx | | > > | xxxxxx | | > > | xxxxxx | | > > | xxxxxx |_| > > | xxxxxx |v| > > +-------------------------+-+ > > > > | padding | width | padding | > > > > | | > > width-scrollbarWidth > > > > > > > > as opposed to this: > > > > +-------------------------+-+ > > | xxxxxxxxx |^| > > | xxxxxxxxx |~| > > | xxxxxxxxx | | > > | xxxxxxxxx | | > > | xxxxxxxxx | | > > | xxxxxxxxx |_| > > | xxxxxxxxx |v| > > +-------------------------+-+ > > > > | padding | width | padding | > > > Yes. This is also what I observe. And this is what the spec states too. > CSS width is to be substracted from the width of scrollbar even though > the scrollbar is located between padding box and border box. So, content > area is shrunk of "xxx" (from 9 "x" to 6 "x" in your ascii example) > > > > > > > As I understand, this behaviour is consistent across browsers, but not > > to be found in the specs. > > > > > > It is found in the spec: > > " > In the case of a scrollbar being placed on an edge of the element's box, > it should be inserted between the inner border edge and the outer > padding edge. Any space taken up by the scrollbars should be taken out > of (subtracted from the dimensions of) the containing block formed by > the element with the scrollbars. > " > 11.1.1 Overflow: the 'overflow' property > http://www.w3.org/TR/CSS21/visufx.html#overflow > > and we have made CSS 2.1 tests in CSS 2.1 test suite about it: > > http://test.csswg.org/suites/css2.1/nightly-unstable/html4/chapter-11.htm#s11.1.1 > > > > > >> The width of vertical scrollbar and the height of horizontal scrollbar > >> are entirely user-settable by os settings. > > > > I understand. The problem is: Firefox does never substract them, no > > matter how wide they are. > > Thomas, Firefox does not substract what from what? > > Firefox 26 does not reduce computedStyle width of the scrollbar width > because scrollbar is considered to be part of CSS width. > > > > > That's because you mixed up content area (the bunch of "xxx" in your > example) and computed style width. > > CSS width is 9 "x" without a scrollbar or 6 "x" with a scrollbar: in > either case, in both cases, the computedStyle CSS width should be the > same. > > The scrollbar is part of CSS width even though it may not be located > inside it: that's tricky. > > ---------- > > <div style="width:20px;padding:20px;overflow:scroll"></div> > > Right here, when I create a test, I try to use values which are unique > and help noticeability, distinctiveness. So, here, I would choose width > and padding values to be different. > > <script> > console.log(getComputedStyle(document.querySelector('div')).width); > </script> Firefox returns '20px', while Chrome returns '5px' (with > scrollbars > > being 15px wide) > > GT: My opinion is that Firefox is correct since width of scrollbar is > part of CSS width. Content area is narrowed by "xxx" in your ascii > example and CSS width still remains 20px. > > > Which one is correct? > > Which Chrome? I get '20px' on Chrome 33.0.1750.51 > > FWIW Chrome 32.0.1700.76 m returns '5px', 34.0.1807.0 canary '3px', > IE 11 '3px' and Opera 18.0 also '3px', while Firefox 26.0 and 29.0a1 > (Nightly) return '20px'. > > GT: My opinion is that there is a small bug with > getComputedStyle(elem).width; Chrome 32, 34 and IE11 should return 20px. > > > Gérard > > > > > Best regards, > > Thomas > >
Received on Tuesday, 28 January 2014 09:37:10 UTC