alert('foobar' == 'foo bar'); // false
alert('foobar' == 'foobar'); // true
alert('foobar' == 'foo\
bar'); // true!
This Jovan fellow writes:
My testing in both FireFox and Rhino showed they both did support these multi-line string literals.
But, sure enough, as best I can tell, the (ECMAScript 3rd edition) spec does not allow for this construct for string literals. Here's the relevant grammar productions for the syntax from the spec:
" DoubleStringCharactersopt "
' SingleStringCharactersopt '
SourceCharacter but not double-quote " or backslash \ or LineTerminator
SourceCharacter but not single-quote ' or backslash \ or LineTerminator
0 [lookahead ∉ DecimalDigit]
SingleEscapeCharacter :: one of
' " \ b f n r t v
SourceCharacter but not EscapeCharacter or LineTerminator
x HexDigit HexDigit
u HexDigit HexDigit HexDigit HexDigit
And, at the end of section 7.8.4, there is the explicit note:
A 'LineTerminator' character cannot appear in a string literal, even if preceded by a backslash \. The correct way to cause a line terminator character to be part of the string value of a string literal is to use an escape sequence such as \n or \u000A.
So, where do these Rhino-and-browser-implementation-supported multi-line string literals come from?
2.3 String Literals: §7.8.4
JScript allows C-style escaped newlines in string literals; according to ES3 this would be a syntax error for unterminated string constant
var s = "this is a \
IE: taken as a single string.
FF: same as IE
Opera: same as IE
Safari: same as IE
IE eats away the '\' and the character following it. The s.length will evaluate to 34 (this includes the leading blanks in the second line). FF, Opera and Safari emulate IE.
Ah ha. (<smarm>It's Microsoft's fault! Why wasn't that obvious from the start?!</smarm>).