Why do textarea `cols` and input text `size` yield different element widths

Question

I am trying to understand the behavior of the cols and size attributes for textarea and input text, respectfully. Although it should be something straight forward, I can't figure out why do they have different widths if the cols and size values are the same?

According to the documentation, both attributes should size the elements so that a given number of characters can fit inside:

...size attribute specifies the visible width, in characters, of an input element. [source - w3schools]

Note the cols and rows attributes (...) specify how many columns tall and rows wide to make the text area. The values are measured in characters . [source - w3]

However if I try to assign the same value to both elements, they end up being with different widths. The input field is a bit too small to accommodate the given number of chars and the the textarea - too wide. Most importantly, both have different width.

For example:

<input type="text" size=40>
<textarea cols="40"></textarea>

produces:

see here - http://jsfiddle.net/yjERR/

I've tried this both in Chrome 29 and Firefox 24.

I understand that width depends on font styles, but shouldn't both elements still have the same width? Are internal element margins or something else causing this difference?

UPDATE

It seems the two elements have different font styles, however assigning the same font-family and font-size still produces different widths:

udpated fiddle

Roband

In your example, input and textarea have different fonts. – Perreault

Answer 1

“Visible width in characters” is a vague expression, since in most fonts, the widths of characters vary. You cannot thus expect to get a control that accommodates an exact number of characters, unless you use a monospace font.

There are two basic things that make the widths of input and textarea differ. First, the default font faces are different: a monospace font for textarea, a sans-serif font for input, in most browsers. This causes different widths, even for the same font size. Second, a textarea widget contains a small area, on the right, that will be used for vertical scroll bar when needed; effectively, the element has overflow: auto by default. You could remove it using overflow: hidden, but then there will be a major problem when the user enters more lines that fit into the area.

If you really want to make the elements equally wide (I don’t think you should), then you can explicitly set the font and the width, e.g.

input, textarea{  
    font-family: Arial, sans-serif;
    font-size: 100%;
    width: 26em; /* fallback for the next one, for browsers not recognizing ch */
    width: 40ch; /* sets the width to 40 times the width of the digit “0” */
}

Ramah

For a number of reasons, including design, I need the elements to be equally wide (yes, obviously easily achievable with width). I was curious why the two attributes produce different results - which you explained very clearly. – Mims

Answer 2

Set both elements the same font-family and it will display correctly.

Here is an example jsFiddle

Perreault

Try adding a <br/> tag in between the input and textarea elements and you will notice that the input is still bigger (albeit by just a bit). – Cannice

You are right about the fonts, it seems the elements are assigned different styles by the user agent. Also the size seems to differ (in Firefox). However, as Harry noted - in your updated fiddle the elements still have a different width. – Mims

set the font size, paste in data, and the textarea is still larger. Is it possible the enlargement is due to the browsers implementation of the stretchable textarea? – Preemie

Actually I just found that if you use CSS width property (say 100px) for both they have the same width. So it should be a problem with/behavior of the size and cols attribute. – Cannice

Answer 3

If the important thing is to get them equally wide easily and precisely, one could use textarea with a row value of 1 instead of an input file.

No doubt a bit late to answer, but it doesn't cost anything...

Hauck