See Ticket #6876 for some background.

When asked for the value of a textarea element, the ".val()" code strips all carriage return characters from the browser-reported value. However, when the value is submitted to the server, carriage returns are preserved (or added, by browsers that ''don't'' include them in the raw value), and (since #6876) jQuery makes sure they're there in the serialized version for XHR purposes.

The problem with this discrepancy between the field as reported by ".val()" and the actual submitted content is that when providing a sort of "maxlength" facility to report on available characters in a textarea, that code must account for the difference in cases where the carriage returns are preserved at the server (in my experience, a very likely thing). In other words, the "character countdown" must take into account the fact that when the textarea value (as reported by jQuery) contains newlines, then its ''actual'' length where it matters -- at the database, or in server-side validation code -- is greater by the number of newlines.

Now obviously this math is easy to do, and there may be all sorts of virtue in stripping those carriage returns. The behavior is not documented clearly, as far as I can tell; it's certainly absent from the description of ".val()". My observation is that in fact this discrepancy is unknown to many authors of exactly the sort of facility I described above.

http://jsfiddle.net/yNKmR/6/ is a crude jsFiddle that submits to a simple CGI script. The page provides a length counter, and the length (both raw and via ".val()") is sent to the server. It's quite clear to see that the posted textarea value contains more actual characters than accounted for by the jQuery ".val()" length. (Firefox and Webkit both behave like jQuery, so the raw length is also wrong.)