5

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.

sergzach
  • 6,578
  • 7
  • 46
  • 84
  • What's the exact problem with the carriage return? – kapa Jun 20 '11 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): http://stackoverflow.com/questions/6140632/how-to-handle-tab-in-textarea – sergzach Jun 20 '11 at 14:53
  • I don't really get what **Tab** has to do with `\r`. – kapa Jun 20 '11 at 14:55
  • You can test in *IE*: set *caret* to zero index of new line and type *Tab*. – sergzach Jun 20 '11 at 15:03

3 Answers3

8

You 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 comment 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.

Pointy
  • 405,095
  • 59
  • 585
  • 614
5

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.

Community
  • 1
  • 1
riwalk
  • 14,033
  • 6
  • 51
  • 68
2

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

Community
  • 1
  • 1
Rafael Herscovici
  • 16,558
  • 19
  • 65
  • 93
  • Thank you Dementic. Excuse me but questions was not about *How to handle tab key*. – sergzach Jun 20 '11 at 15:40
  • @Buh Buh - Yeah.. ill try not overthink anymore... ;) @segzach - you are right, that is not the question. But, it DOES provide a solution to your problem. – Rafael Herscovici Jun 21 '11 at 09:22
  • @Dementic OK, if you think so. I have voted up your answer. At first glance it seemed you missed the sense of question. I will view your decision later. Thank you. – sergzach Jun 22 '11 at 07:58
  • well, if the problem is that tab inserts a new line character, then taking over the tab behaviour and remove that new line character is just logical. – Rafael Herscovici Jun 22 '11 at 08:04
  • OK, the problem was you have just said about. – sergzach Jun 22 '11 at 10:00