ECMA compliance: escaped newline in JS string literals

VERIFIED WONTFIX

Status

()

defect
--
minor
VERIFIED WONTFIX
18 years ago
2 years ago

People

(Reporter: jim, Assigned: waldemar)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
From the End of 7.8.4 ECMAScript Ed. 3

"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."

However:

<SCRIPT>
alert("   Line 1    \
          Line 2    \
          Line 3")
</script>

Does not cause an error, no linefeeds are contained within the string on win98, 
this is the same as JScript, but different to JavaScript pre 1.5 and Opera's 
implementation.

I've logged this bug as Minor, because I do not believe it should be fixed, It 
is not an error in any ECMAScript implementation I've tested, and Microsoft 
have suggested they won't fix it.  Some Petitioning of ECMA-262 to Change the 
Standard for Ed.4 to include the existing behaviour would be more productive in 
my opinion.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Escaped newline in javascript String Literal ECMAScript Ed.3 non-compliance → Escaped newline in javascript String Literal ECMAScript Ed.3
(Reporter)

Comment 1

18 years ago
Just to note, that Roger Lawrence, the assigned person states this is the 
behaviour in:

http://groups.google.com/groups?selm=39205AA8.FE081514%40netscape.com

However, that thread doesn't continue and in other ECMAScript implementations 
it is UA/platform specific as to whether the newlines are included in escaped 
literals, hence why I feel no fix, but petition ECMA-262 to codify the correct 
behaviour.

Comment 3

18 years ago
Summary of the escape sequence "\(literal newline character)"


NN4.7 (JS1.4)  
The newline character is treated as any other non-escaped character.
Escaping a non-escaped character results in the character itself ("\A" == "A").
Thus the newline character gets included in the string as itself.


Moz/N6 (JS1.5)
The newline character is discarded and the string is produced without it.
No error is thrown.


ECMA Ed. 3  7.8.4 String Literals
NonEscapeCharacter :: 
     SourceCharacter but not EscapeCharacter or LineTerminator 

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.

Comment 4

18 years ago
Assigning this to Waldemar for a decision -

Do we want JS1.5 to throw an error on "\(literal newline character)" ?
If not, is the behavior of JS1.4 preferable, in the way it allows this
as line continuation for the programmer? 

From a standards viewpoint, should ECMA be changed to allow this?
Assignee: rogerl → waldemar
OS: Windows 98 → All
Hardware: PC → All
Summary: Escaped newline in javascript String Literal ECMAScript Ed.3 → ECMA compliance: escaped newline in JS string literals
(Reporter)

Comment 5

18 years ago
Waldemar has hopefully already made the decision!

See: http://groups.google.com/groups?th=799d6206f3c9a3d,2

I believe it definately cannot be an error, there's a small number of posts in 
Groups.Google specifying \ as the "line continuation" character in javascript, 
and I think it's likely that the approach is used on existing pages, and 
there's no reason to break those pages to be compliant to a minor point of a 
standard that no-one else is and JScript at least have made the decision to be 
non-compliant on the same grounds.

The question as you say is what ends up in the String? on your test case (which 
has CRLF linefeed it seems), NN4.7 has CharCode 10, Opera 5 has CharCode 13, 
and IE/Mozilla has no charcode at all. (incidently stringvalue[i] is not 
ECMAScript either.)

It's my belief that those users who have used it as a line continuation 
character would not expect a newline to be contained in the resulting String 
object, although the devedge page in the google link above is an alternative 
use. (Of course Devedge is hardly a site to hold up as an example of good 
scripting.)
(Assignee)

Comment 6

18 years ago
ECMAScript is clear on this -- a backslash followed by any kind of a line break
is a syntax error.  I don't think we can make this into a syntax error in JS1.5
because of compatibility concerns with existing scripts.  In our Edition 4
strict mode implementation I'd expect this to really be a syntax error.

An implementation is allowed to (but discouraged from) extend any behavior that
the standard says would cause a syntax error, so what we're currently doing in
JS1.5 is strictly speaking ECMA-conforming but frowned upon because it confuses
scripters and makes scripts unnecessarily nonportable, as illustrated by Jim's
analysis above.

Comment 7

18 years ago
Just spoke with Waldemar - marking this one, then, as WONTFIX
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 8

18 years ago
Marking Verified - 

Jim, thank you for this report.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.