User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:184.108.40.206) Gecko/20100625 Firefox/3.6.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:220.127.116.11) Gecko/20100625 Firefox/3.6.6
The property element.scrollHeight does not include padding of a text area, but for a div it includes both padding AND border. This is not according to the documentation at https://developer.mozilla.org/en/DOM/element.scrollHeight
Steps to Reproduce:
1. Use a text area with padding.
2. Compute the scroll height.
Scroll height = height, but not including padding.
Scroll height should be height including padding.
For a div, the situation is again different: border seems to be included there as well.
Created attachment 456053 [details]
Scroll height examples for text area / div
Click the text area / div to view computed scroll height values.
I can see the same behaviour. scrollHeight includes height + padding + border.
clientHeight includes heigth + padding.
So, clientHeight is not the same as scrollHeight for non scrollable elements.
Opera behaves the same way as firefox, while webkit behaves the same way as described in the documentation.
I'll attach another testcase
Created attachment 498711 [details]
testcase: show difference between clientHeight and scrollHeight
This behaviour also makes it impossible to ascertain whether or not overflow has occurred in a div, because even an empty div with a fixed height of, say, 123px will report a clientHeight of 123px but a scrollHeight of 123 + border-top + border-bottom, which is the only way to test whether or not overflow has occurred.
problem touches on what was filed at http://code.google.com/p/chromium/issues/detail?id=74999
*** Bug 740670 has been marked as a duplicate of this bug. ***
Boris, could that be related to bug 157846?
Better if I CC him...
Boris, could you look at comment 6? :)
Seems plausible, yes. We really need a spec for form controls....
See related: bug 735646. It has patches that change scrollHeight to not include the border. That should fix half of this bug (the div half, not the textarea half).
Oops, I meant bug 755971. That has landed on inbound now, but I'll leave this open since I'm not sure if there are other unresolved issues here.