Closed
Bug 92944
Opened 23 years ago
Closed 23 years ago
ECMA compliance: escaped newline in JS string literals
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: jim, Assigned: waldemar)
Details
Attachments
(1 file)
1.52 KB,
text/html
|
Details |
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.
Updated•23 years ago
|
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
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 2•23 years ago
|
||
Comment 3•23 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•23 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
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•23 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•23 years ago
|
||
Just spoke with Waldemar - marking this one, then, as WONTFIX
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Comment 8•23 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.
Description
•