- 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