Closed
Bug 484257
Opened 16 years ago
Closed 16 years ago
clientWidth/Height and scrollWidth/Height don't include the padding on textareas
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
DUPLICATE
of bug 157846
People
(Reporter: ojan, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
1.54 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7 GTB3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7 GTB3 The metrics on textareas should match those of a div with box-sizing:border-box. Stated differently, clientWidth/Height and scrollWidth/Height include the padding on every other element. They should include the padding on textareas as well. Reproducible: Always Steps to Reproduce: Reduced test page coming.
Reporter | ||
Comment 1•16 years ago
|
||
Updated•16 years ago
|
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Comment 2•16 years ago
|
||
Here are the relevant parts of the layout object dumps: HTMLScroll(div)(2)@0x166c6b4 [view=0x9a1e580] next=0x1671f9c {0,4416,3000,3000} [state=00042010] [content=0x9a1bce0] [sc=0x166c204]< Block(div)(2)@0x1671f20 [view=0x9a23780] {120,120,2760,2760} [state=00d02000] sc=0x1671df8(i=0,b=0) pst=:-moz-scrolled-content< That's in units of 1/60 of a px, so the scrollable thing is 50x50 in px, and the thing inside it is 46x46. nsTextControlFrame@0x1672024 next=0x166f748 {0,7476,3000,3000} [state=80c44010] [content=0x9a1c0a0] [sc=0x166c39c]< HTMLScroll(div)(-1)@0x16722d8 [view=0x9a23ef0] {300,300,2400,2400} [state=000c6010] [content=0x9a23800] [sc=0x166fa20]< Block(div)(-1)@0x166f6cc [view=0x9a24cc0] {0,0,2400,2400} [state=00d06000] sc=0x166f574(i=1,b=0) pst=:-moz-scrolled-content< So the point is, the scrollable thing is not the textarea itself but a div inside it. While the textarea is 50x50px, the scrollable thing is 40x40, as is the block it scrolls. Hence the numbers you see. The reason the scrollable thing is 40x40 is that it's just a scrollable block inside an ancestor which has border-size 50x50 and has 10px topbottom and leftright borderpadding (6px padding, 4px border). So looks like everything is correct: offsetWidth/Height is reporting the size of the box, while scroll* and client* report the size of the scrollable area. It's just that the scrollable areas are different in the two cases, because the replaced element for the form control has a somewhat more complicated CSS box structure inside it.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 3•16 years ago
|
||
Ok, well, the bug is that the scroll is on the div inside the textarea. Is there a reason for that or is it just an accident of history? Anyways, it turns out there is already a bug filed for this. Resolving as a duplicate.
Resolution: INVALID → DUPLICATE
Reporter | ||
Comment 4•16 years ago
|
||
Also that this does not match the definitions of clientHeight/Width and scrollHeight/Width at https://developer.mozilla.org/en/DOM/element.clientHeight or at http://www.w3.org/TR/cssom-view/ which include the padding. I understand that under the hood it's implemented with a nested div, but those implementation details should not be visible to web developers.
Comment 5•16 years ago
|
||
> Is there a reason for that or is it just an accident of history? Some of both. > those implementation details should not be visible to web developers. Would web developers prefer that the scroll* properties not match the actual scrolling area? Or something else? In any case, the fact of the matter is, you're querying box model details on a replaced element. Behavior will be implementation-dependent. That's what it means to be a replaced element.... It's not happy, but it's life.
You need to log in
before you can comment on or make changes to this bug.
Description
•