Right now, if a textarea has the following CSS style declarations width:100px, height:100px and padding:20px; the available space allocated for text content will be 60px and not 100px. This is a clear spec violation of W3C CSS2 box model. Test case following.

Self-explanatory test case. The only different css declaration is the padding value. The textarea on the left side has a 1px padding value. The textarea on the right side has a 23px padding value. Note: MSIE 6 correctly renders the width, height and padding values according to W3C CSS1 box model. Actual results: Mozilla allocates 100px for padding and content. Expected results: Mozilla should allocate 100px for content (width and height) according to W3C CSS2 box model, regardless of padding values, borders, presence of scrollbars.

Reference: <http://www.w3.org/TR/REC-CSS2/box.html#box-dimensions> "The box width is given by the sum of the left and right margins, border, and padding, and the content width." Therefore in a box with 100px width, the 100px includes the 20px padding to the left/right. Therefore the actual content width is 100-20-20=60px. IE6 has a quirks and a standards mode. It should do as you describe in your bug summary in quirks mode and behave as Mozilla in standards mode. If your IE was in standards mode and acted this way, then you have found an IE6 bug. For Mozilla, this is an invalid bug.

Unfortunately, the 'width' and 'height' properties give the width and height of the _content_ area, not the box. So this is a valid bug. However, the cause is that we have a secret '-moz-box-sizing' property (which is based on something from CSS3) which changes our behaviour specifically for textarea and input elements. If you want to get the CSS2 behaviour, then set: *|* { -moz-box-sizing: content-box; } ...in your stylesheet.

This is also one of the problems with allowing CSS properties like padding to apply to the internals of form controls, where they don't really make sense.

http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-width says: The width "property specifies the content width of boxes generated by block-level and replaced elements. This property does not apply to non-replaced inline-level elements. The width of a non-replaced inline element's boxes is that of the rendered content within them (...)" and here <dismay><gasp><surprise> textarea is not a block-level element but an inline non-replaced element. I really thought textarea was a block-level element. I was wrong. http://www.w3.org/TR/html401/sgml/dtd.html#formctrl says: <!-- %inline; covers inline or "text-level" elements --> <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"> <!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON"> So, this bug 157847 is invalid. Sorry. Re: comment 4: IMO, padding should apply to textarea but it should be located between scrollbars (if present) and content, not between borders and scrollbars (see bug 157846). In a paragraph with scrollbars, padding is displayed between scrollbars and content.

TEXTAREA is neither inline nor block -- it's inline-block, something that isn't described in CSS2 but to which the width and height properties should apply once it's defined. Regarding position of padding relative to scrollbars -- TEXTAREA is different from P since the scrollbars are an intrinsic part of the replaced content rather than something specified by the author. (Then again, nobody else likes my opinions on CSS and form controls.)