Question

Sample HTML/CSS:

<div class="container">
    <input type="text" />
    <div class="filler"></div>
</div>

div.container {
    padding: 5px;
    border: 1px solid black;
    background-color: gray;
}

div.filler {
    background-color: red;
    height: 5px;
}

input {
    display: block;
}

http://jsfiddle.net/bPEkb/3/

Question

Why doesn’t the input box expand to have the same outer width as, say div.filler? That is to say, why doesn’t the input box expand to fit its container like other block elements with width: auto; do?

I tried checking the “User Agent CSS” in Firebug to see if I could come up with something there. No luck. I couldn’t find any specific differences in CSS that I could specifically link to the input box behaving differently from the regular div.filler.

Besides curiousity, I’d like to know why this is to get to the bottom of it to figure out a way to set width once and forget it. My current practice of explicitly setting the width of both input and its containing block element seems redundant and less than modular. While I’m familiar with the technique of wrapping the input element in a div then assigning to the input element negative margins, this seems quite undesirable.

borkweb and Phrogz have both provided exceptional information that takes advantage of the border-box box model from the old days. Thanks for this! I’d like to reiterate the focus of my question that I intend to keep distinct from the proposed solution to my practical problem:

What about the specification causes input boxes to be formatted unlike ordinary block elements like divs? The border-box solution is wonderful, but it doesn’t satisfy the desire to figure out why input boxes are this way in the first place and why they can’t be made to behave exactly like ordinary divs, which do not use the border-box model these days.

Answer 1

Alright, due to the clarification of the original question…I did some digging and found these laments and this article.

There are a few elements (<input>, <select>, <button>, <img>, <object>, and <textarea>) that are considered replaced elements whose appearance and dimensions are defined by an external resource. (e.g. the operating system, a plugin, etc)

Replaced elements can have intrinsic
dimensions—width and height values
that are defined by the element
itself, rather than by its
surroundings in the document. For
example, if an image element has a
width set to auto, the width of the
linked image file will be used.
Intrinsic dimensions also define an
intrinsic ratio that’s used to
determine the computed dimensions of
the element should only one dimension
be specified. For example, if only the
width is specified for an image
element—at, say, 100px—and the actual
image is 200 pixels wide and 100
pixels high, the height of the element
will be scaled by the same amount, to
50px.

Replaced elements can also have visual
formatting requirements imposed by the
element, outside of the control of CSS;
for example, the user interface controls
rendered for form elements.

W3C’s CSS 2.1 “Visual Formatting Model Details” section discusses the calculation of widths of both replaced and non-replaced elements.

Overall…pretty annoying for some form elements (<textarea>, <button>, and <input>). Can/will it change? Probably not any time soon…Until it does change at the core, we’ll have to stick with the hacks 🙁