We have a multiline textarea in Internet Explorer.
If we check it's content after the next then everything is correct (there are no extra carriage returns in textarea):
document.getElementById( 'text-area' ).value = "Hello,\nWorld!";
But if we set caret to the beginning position of the second line (in Internet Explorer, not in the code) and press tab key there is an extra carriage character (there is a string dump on keydown below):
value[0]='H'
value[1]='e'
value[2]='l'
value[3]='l'
value[4]='o'
value[5]=','
value[6]='\r'
value[7]='\n'
value[8]='W'
value[9]='o'
value[10]='r'
value[11]='l'
value[12]='d'
value[13]='!'
It's a problem because other browsers don't insert extra carriage return.
Do you know how to prevent this in Internet Explorer? With help of CSS or Javascript.
We have a multiline textarea in Internet Explorer.
If we check it's content after the next then everything is correct (there are no extra carriage returns in textarea):
document.getElementById( 'text-area' ).value = "Hello,\nWorld!";
But if we set caret to the beginning position of the second line (in Internet Explorer, not in the code) and press tab key there is an extra carriage character (there is a string dump on keydown below):
value[0]='H'
value[1]='e'
value[2]='l'
value[3]='l'
value[4]='o'
value[5]=','
value[6]='\r'
value[7]='\n'
value[8]='W'
value[9]='o'
value[10]='r'
value[11]='l'
value[12]='d'
value[13]='!'
It's a problem because other browsers don't insert extra carriage return.
Do you know how to prevent this in Internet Explorer? With help of CSS or Javascript.
Share Improve this question edited Sep 13, 2011 at 19:01 sergzach asked Jun 20, 2011 at 14:44 sergzachsergzach 6,7647 gold badges51 silver badges86 bronze badges 4- What's the exact problem with the carriage return? – kapa Commented Jun 20, 2011 at 14:48
- I would like to handle the situation when user presses tab character in textarea. In case of Internet Explorer there is a problem (the next answer does not work properly): stackoverflow./questions/6140632/… – sergzach Commented Jun 20, 2011 at 14:53
-
I don't really get what Tab has to do with
\r. – kapa Commented Jun 20, 2011 at 14:55 - You can test in IE: set caret to zero index of new line and type Tab. – sergzach Commented Jun 20, 2011 at 15:03
3 Answers
Reset to default 8You cannot prevent it, and you probably shouldn't anyway. Despite the fact that IE and other browsers differ in the way that they report the value of <textarea> elements, all browsers actually do include "\r\n" for all hard line breaks in the value when the form surrounding the element is submitted. In other words, even though Firefox reports line breaks as consisting of just "\n", it's actually lying to you — when the form is posted, the value will have "\r" in there too.
For some reason, jQuery normalizes the behavior across browsers by stripping out the "\r" characters, which of course is the wrong thing to do. It means that when you're trying to count characters (like the Stackoverflow ment box), you have to take into account the fact that each single "\n" character actually represents two characters at the server. Thus you have to either strip out the "\r" on the server, or, probably better, account for it in the client-side validation code.
My best suggestion is that you adjust your way of thinking about the problem.
As was mentioned here, there is no universal newline character. Some operating systems use \n, others use \r\n, and there were still others that used \r.
The HTTP protocol specifies \r\n as the newline character that should be used between headers, so every browser has to (in some way) think of a newline as \r\n. If you ever want to use a line return, just use \r\n. You'll have fewer headaches that way.
what you can do is takeover the tab keypress and replace it with your own selection:
see here for a solution :
jQuery: How to capture the TAB keypress within a Textbox