Understanding offsetWidth, clientWidth, scrollWidt

Question

There are several questions on StackOverflow regarding offsetWidth/clientWidth/scrollWidth (and -Height, respectively), but none give comprehensive explanation of what those values are.

Also, there are several sources on the web giving confusing or incorrect information.

Can you give a complete explanation including some visual hints? Also, how can those values be used to calculate scroll bar widths?

Answer 1

The CSS box model is rather complicated, particularly when it comes to scrolling content. While the browser uses the values from your CSS to draw boxes, determining all the dimensions using JS is not straight-forward if you only have the CSS.

That's why each element has six DOM properties for your convenience: offsetWidth, offsetHeight, clientWidth, clientHeight, scrollWidth and scrollHeight. These are read-only attributes representing the current visual layout, and all of them are integers (thus possibly subject to rounding errors).

Let's go through them in detail:

• offsetWidth, offsetHeight: The size of the visual box incuding all borders. Can be calculated by adding width/height and paddings and borders, if the element has display: block
• clientWidth, clientHeight: The visual portion of the box content, not including borders or scroll bars , but includes padding . Can not be calculated directly from CSS, depends on the system's scroll bar size.
• scrollWidth, scrollHeight: The size of all of the box's content, including the parts that are currently hidden outside the scrolling area. Can not be calculated directly from CSS, depends on the content.

Try it out: jsFiddle

---

Since offsetWidth takes the scroll bar width into account, we can use it to calculate the scroll bar width via the formula

scrollbarWidth = offsetWidth - clientWidth - getComputedStyle().borderLeftWidth - getComputedStyle().borderRightWidth

Unfortunately, we may get rounding errors, since offsetWidth and clientWidth are always integers, while the actual sizes may be fractional with zoom levels other than 1.

Note that this

scrollbarWidth = getComputedStyle().width + getComputedStyle().paddingLeft + getComputedStyle().paddingRight - clientWidth

does not work reliably in Chrome, since Chrome returns width with scrollbar already substracted. (Also, Chrome renders paddingBottom to the bottom of the scroll content, while other browsers don't)

Answer 2

There is a good article on MDN that explains the theory behind those concepts: https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Determining_the_dimensions_of_elements

It also explains the important conceptual differences between boundingClientRect's width/height vs offsetWidth/offsetHeight.

Then, to prove the theory right or wrong, you need some tests. That's what I did here: https://github.com/lingtalfi/dimensions-cheatsheet

It's testing for chrome53, ff49, safari9, edge13 and ie11.

The results of the tests prove that the theory is generally right. For the tests, I created 3 divs containing 10 lorem ipsum paragraphs each. Some css was applied to them:

.div1{
    width: 500px;
    height: 300px;
    padding: 10px;
    border: 5px solid black;
    overflow: auto;
}
.div2{
    width: 500px;
    height: 300px;
    padding: 10px;
    border: 5px solid black;
    box-sizing: border-box;
    overflow: auto;
}

.div3{
    width: 500px;
    height: 300px;
    padding: 10px;
    border: 5px solid black;
    overflow: auto;
    transform: scale(0.5);
}

And here are the results:

• div1

  • offsetWidth: 530 (chrome53, ff49, safari9, edge13, ie11)
  • offsetHeight: 330 (chrome53, ff49, safari9, edge13, ie11)
  • bcr.width: 530 (chrome53, ff49, safari9, edge13, ie11)

  • bcr.height: 330 (chrome53, ff49, safari9, edge13, ie11)

  • clientWidth: 505 (chrome53, ff49, safari9)

  • clientWidth: 508 (edge13)
  • clientWidth: 503 (ie11)

  • clientHeight: 320 (chrome53, ff49, safari9, edge13, ie11)

  • scrollWidth: 505 (chrome53, safari9, ff49)

  • scrollWidth: 508 (edge13)
  • scrollWidth: 503 (ie11)
  • scrollHeight: 916 (chrome53, safari9)
  • scrollHeight: 954 (ff49)
  • scrollHeight: 922 (edge13, ie11)

• div2

  • offsetWidth: 500 (chrome53, ff49, safari9, edge13, ie11)
  • offsetHeight: 300 (chrome53, ff49, safari9, edge13, ie11)
  • bcr.width: 500 (chrome53, ff49, safari9, edge13, ie11)
  • bcr.height: 300 (chrome53, ff49, safari9)
  • bcr.height: 299.9999694824219 (edge13, ie11)
  • clientWidth: 475 (chrome53, ff49, safari9)
  • clientWidth: 478 (edge13)
  • clientWidth: 473 (ie11)

  • clientHeight: 290 (chrome53, ff49, safari9, edge13, ie11)

  • scrollWidth: 475 (chrome53, safari9, ff49)

  • scrollWidth: 478 (edge13)
  • scrollWidth: 473 (ie11)
  • scrollHeight: 916 (chrome53, safari9)
  • scrollHeight: 954 (ff49)
  • scrollHeight: 922 (edge13, ie11)

• div3

  • offsetWidth: 530 (chrome53, ff49, safari9, edge13, ie11)
  • offsetHeight: 330 (chrome53, ff49, safari9, edge13, ie11)
  • bcr.width: 265 (chrome53, ff49, safari9, edge13, ie11)
  • bcr.height: 165 (chrome53, ff49, safari9, edge13, ie11)
  • clientWidth: 505 (chrome53, ff49, safari9)
  • clientWidth: 508 (edge13)
  • clientWidth: 503 (ie11)

  • clientHeight: 320 (chrome53, ff49, safari9, edge13, ie11)

  • scrollWidth: 505 (chrome53, safari9, ff49)

  • scrollWidth: 508 (edge13)
  • scrollWidth: 503 (ie11)
  • scrollHeight: 916 (chrome53, safari9)
  • scrollHeight: 954 (ff49)
  • scrollHeight: 922 (edge13, ie11)

So, apart from the boundingClientRect's height value (299.9999694824219 instead of expected 300) in edge13 and ie11, the results confirm that the theory behind this works.

From there, here is my definition of those concepts:

• offsetWidth/offsetHeight: dimensions of the layout border box
• boundingClientRect: dimensions of the rendering border box
• clientWidth/clientHeight: dimensions of the visible part of the layout padding box (excluding scroll bars)
• scrollWidth/scrollHeight: dimensions of the layout padding box if it wasn't constrained by scroll bars

Note: the default vertical scroll bar's width is 12px in edge13, 15px in chrome53, ff49 and safari9, and 17px in ie11 (done by measurements in photoshop from screenshots, and proven right by the results of the tests).

However, in some cases, maybe your app is not using the default vertical scroll bar's width.

So, given the definitions of those concepts, the vertical scroll bar's width should be equal to (in pseudo code):

• layout dimension: offsetWidth - clientWidth - (borderLeftWidth + borderRightWidth)

• rendering dimension: boundingClientRect.width - clientWidth - (borderLeftWidth + borderRightWidth)

Note, if you don't understand layout vs rendering please read the mdn article.

Also, if you have another browser (or if you want to see the results of the tests for yourself), you can see my test page here: http://codepen.io/lingtalfi/pen/BLdBdL

Answer 3

I created a more comprehensive and cleaner version that some people might find useful for remembering which name corresponds to which value. I used Chrome Dev Tool's color code and labels are organized symmetrically to pick up analogies faster:

• Note 1: clientLeft also includes the width of the vertical scroll bar if the direction of the text is set to right-to-left (since the bar is displayed to the left in that case)

• Note 2: the outermost line represents the closest positioned parent (an element whose position property is set to a value different than static or initial). Thus, if the direct container isn’t a positioned element, then the line doesn’t represent the first container in the hierarchy but another element higher in the hierarchy. If no positioned parent is found, the browser will take the html or body element as reference

---

Hope somebody finds it useful, just my 2 cents ;)

Answer 4

If you want to use scrollWidth to get the "REAL" CONTENT WIDTH/HEIGHT (as content can be BIGGER than the css-defined width/height-Box) the scrollWidth/Height is very UNRELIABLE as some browser seem to "MOVE" the paddingRIGHT & paddingBOTTOM if the content is to big. They then place the paddings at the RIGHT/BOTTOM of the "too broad/high content" (see picture below).

==> Therefore to get the REAL CONTENT WIDTH in some browsers you have to substract BOTH paddings from the scrollwidth and in some browsers you only have to substract the LEFT Padding.

I found a solution for this and wanted to add this as a comment, but was not allowed. So I took the picture and made it a bit clearer in the regard of the "moved paddings" and the "unreliable scrollWidth". In the BLUE AREA you find my solution on how to get the "REAL" CONTENT WIDTH!

Hope this helps to make things even clearer!