A complication of <textarea>
countdown effects stems from the fact that, almost unbelievably, the length that browsers report for a <textarea>
element value is not necessarily the actual length of the string that they'll send back to the server when the form is posted.
Here is a jsfiddle that demonstrates the issue. If you type some characters into the <textarea>
, the script in the page will update a counter with the current length of the field's value. Type in a couple of characters, hitting "Enter" in between a couple times. Note the length reported. (Hitting "Enter" explicitly is important, as the problem involves explicit newlines.)
If you then click "Go", the server will respond with the HTTP request contents. Count the size of the value of "b" (the name of the <textarea>
in the form). Note in particular that newlines are sent as two-character sequences. The browser, however, counts embedded newlines as a single character. Thus, each embedded explicit newline causes the reported length to be 1 less than the length that'll actually be submitted.
That discrepancy can be important, depending on what happens at your server when the parameter is extracted from the HTTP request body. I imagine some server-side environments might fold the CR-LF pairs into plain LF characters, thus getting the effective string length back in harmony with what was reported by the browser before form submittal. However, in my experience, that doesn't happen automaticaly, and in fact you might really not want that behavior anyway. Your server will be checking the length anyway before it saves, or at least the database server will if the ultimate destination is a text column with a maximum length, but it's bad form for the validation code on the page to report an OK situation only for that to be contradicted by a nasty error coming back from the server.
Many of the off-the-shelf JavaScript tools for providing a counter do not account for this behavior.