What character represents a new line in a text area

Just quick one, but want to make sure I'm catching cross platform variations.

I like to convert new lines entered into a text area into a [comma], so that the output can be represented on a single line, my question...

Currently, sending from google chrome, when I view the value, I find it uses \r\n for new lines. If I replace \r\n I know it will work for chrome on windows 7, but what about other platforms, are there variations on what other browsers will insert as a new line inside a text area?

By HTML specifications, browsers are required to canonicalize line breaks in user input to CR LF (\r\n), and I don’t think any browser gets this wrong. Reference: clause 17.13.4 Form content types in the HTML 4.01 spec.

In HTML5 drafts, the situation is more complicated, since they also deal with the processes inside a browser, not just the data that gets sent to a server-side form handler when the form is submitted. According to them (and browser practice), the textarea element value exists in three variants:

1. the raw value as entered by the user, unnormalized; it may contain CR, LF, or CR LF pair;
2. the internal value, called “API value”, where line breaks are normalized to LF (only);
3. the submission value, where line breaks are normalized to CR LF pairs, as per Internet conventions.

Talking specifically about textareas in web forms, for all textareas, on all platforms, \r\n will work.

If you use anything else you will cause issues with cut and paste on Windows platforms.

The line breaks will be canonicalised by windows browsers when the form is submitted, but if you send the form down to the browser with \n linebreaks, you will find that the text will not copy and paste correctly between for example notepad and the textarea.

Interestingly, in spite of the Unix line end convention being \n, the standard in most text-based network protocols including HTTP, SMTP, POP3, IMAP, and so on is still \r\n. Yes, it may not make a lot of sense, but that's history and evolving standards for you!

It seems that, according to the HTML5 spec, the value property of the textarea element should return '\r\n' for a newline:

> The element's value is defined to be the element's raw value > with the following transformation applied: > > Replace every occurrence of a "CR" (U+000D) character not followed by > a "LF" (U+000A) character, and every occurrence of a "LF" (U+000A) > character not preceded by a "CR" (U+000D) character, by a > two-character string consisting of a U+000D CARRIAGE RETURN "CRLF" > (U+000A) character pair.

Following the link to 'value' makes it clear that it refers to the value property accessed in javascript:

> Form controls have a value and a checkedness. (The latter is only used > by input elements.) These are used to describe how the user interacts > with the control.

However, in all five major browsers (using Windows, 11/27/2015), if '\r\n' is written to a textarea, the '\r' is stripped. (To test: var e=document.createElement('textarea'); e.value='\r\n'; alert(e.value=='\n');) This is true of IE since v9. Before that, IE was returning '\r\n' and converting both '\r' and '\n' to '\r\n' (which is the HTML5 spec). So... I'm confused.

To be safe, it's usually enough to use '\r?\n' in regular expressions instead of just '\n', but if the newline sequence must be known, a test like the above can be performed in the app.


- Line Feed and 
 Carriage Return

These HTML entities will insert a new line or carriage return inside a text area.