When does whitespace in JavaScript matter?

[Peter Michaux]

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new line
character matters.

Any others?

Thanks,
Peter

[Randy Webb]

Peter Michaux said the following on 1/8/2007 2:58 PM:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

In those 4 instances where whitespace will matter I always wrap it in
parentheses to remove the whitespace issue.

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new line
character matters.

That is not always true though:

function someFunction()
{

The newline character there is irrelevant. But, if you replace all new
lines with ;\n then you break the code. Line feeds and semicolons are a
spot where you have to either do it manually or write a JS parser.

Another example where the newline can't be summarily replaced but the
newline doesn't matter is in a loop:

for (i in something)
while(yourWifeIsntPregnant)

Whether the { is on the same line or the next line doesn't matter, the
newline is still irrelevant yet there is no semicolon at the end of it.

You can't summarily say "don't put a semicolon after )" either. Think of
anonymous functions....()
You could check ) to see if it is () or ) but it can still get you in
trouble with a function with no parameter:

function myFunction()
{

}

Where the newline character can't be replaced with a ;newline but if
it's a global anonymous function and you want to remove newlines then
you *must* have the semicolon or it breaks the code.

var x = (function(){
//some code here
})();

Can't remove the semicolon and the newline, one has to be there.

Semicolons and newlines will become your new nightmare :)

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Duncan Booth]

"Peter Michaux" <pe**********@gmail.comwrote:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new line
character matters.

The new line character only matters some of the time. Unfortunately you
aren't going to know whether or not it matters without doing a full parser.

>
Any others?

A keyword followed by a letter or digit: "return 42;" versus "return42;"

Inside strings and regular expressions.

A comment which immediately follows a division:
a = x / /*this had better not be zero: */y;
z = 1;
versus:
a = x //*this had better not be zero: */y;
z = 1;

[Peter Michaux]

Randy Webb wrote:

Peter Michaux said the following on 1/8/2007 2:58 PM:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

<snip>

Semicolons and newlines will become your new nightmare :)

I imagine so. I may just decide to leave new lines in place.

It's more the comments, blank lines and beginning or mid-line spaces
that are a bigger concern. I have been using jslint to check for
problems before jsmin but jslint has many programmer preferences built
in and not just outright problems that will be harmful when minimizing.
I suppose I could strip jslint down.

What I really want is a command I can type inside a directory that
checks if the javascript files in that directory are minimizable and if
so minimizes them. Following that step all the files are gzipped. This
will save Apache the trouble of having to use mod_deflate for every
single request for a file. I don't know why they didn't build caching
for this into mod_deflate but since I have to do the minimize step
anyway I can also piggy back the compression step on the same command.
I know one thing for sure: I don't want to have to do all this
deployment stuff by hand starting with http://jslint.com anymore.

Peter

[Duncan Booth]

"Peter Michaux" <pe**********@gmail.comwrote:

It's more the comments, blank lines and beginning or mid-line spaces
that are a bigger concern. I have been using jslint to check for
problems before jsmin but jslint has many programmer preferences built
in and not just outright problems that will be harmful when minimizing.
I suppose I could strip jslint down.

I did a modified version of jslint which might interest you. You can find
it at http://codespeak.net/svn/kupu/trunk/kupu

The difference is that with my version there are command line options to
suppress most of the warnings so if you decide that you don't mind spurious
semicolons just use --ignore to suppress the ones you don't want. All the
warnings are numbered. See jslint.opts for the options I use for kupu, also
lint.py for a script which runs jslint.js over modified .js files only.
Also error messages all begin with filename and line number so they are
easily parsed by most editors.

Usage:
--
--browser, --nobrowser*
true if the standard browser globals should be predefined
--cap, --nocap*
true if upper case HTML should be allowed
--debug, --nodebug*
true if debugger statements should be allowed
--eqeqeq, --noeqeqeq*
true if === should be required
--error #
Specified messages are fatals
--evil, --noevil*
true if eval should be allowed
--extern #
Add external names
--help
show usage text
--ignore #
Specified messages are ignored
--jscript, --nojscript*
true if jscript deviations should be allowed
--laxLineEnd, --nolaxLineEnd*
true if line breaks should not be checked
--options #
Read additional arguments and options from a file
--passfail, --nopassfail*
true if the scan should stop on first error
--plusplus, --noplusplus*
true if increment/decrement should not be allowed
--redef, --noredef*
true if var redefinition should be allowed
--undef, --noundef*
true if undefined variables are errors
--warn #
Specified messages are warnings
--widget, --nowidget*
true if the Yahoo Widgets globals should be predefined

[VK]

Peter Michaux wrote:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new line
character matters.

Any others?

I guess Books of ECMA, Book of Tokens is the first place to look for
(ECMAScript 3rd ed., sec.7, "Lexical Conventions")

Besides that there is one cross-browser exception to add, but the book
above first.

[Peter Michaux]

Duncan Booth wrote:

"Peter Michaux" <pe**********@gmail.comwrote:

It's more the comments, blank lines and beginning or mid-line spaces
that are a bigger concern. I have been using jslint to check for
problems before jsmin but jslint has many programmer preferences built
in and not just outright problems that will be harmful when minimizing.
I suppose I could strip jslint down.

I did a modified version of jslint which might interest you. You can find
it at http://codespeak.net/svn/kupu/trunk/kupu

Thanks for the link. Your version may come in very handy.

Peter

[Peter Michaux]

VK wrote:

Peter Michaux wrote:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new line
character matters.

Any others?

I guess Books of ECMA, Book of Tokens is the first place to look for
(ECMAScript 3rd ed., sec.7, "Lexical Conventions")

Besides that there is one cross-browser exception to add, but the book
above first.

What is the exception?

Peter

[VK]

Peter Michaux wrote:

I guess Books of ECMA, Book of Tokens is the first place to look for
(ECMAScript 3rd ed., sec.7, "Lexical Conventions")

Besides that there is one cross-browser exception to add, but the book
above first.

What is the exception?

You are free to disregard, because it is not officially required by
specs, just an exploit of the internal tokenizer mechanics. Yet if it's
for public use - they you may account it as well. Any way, for long
string literals (too long to place on one line) instead of
concatenation one uses sometimes backslash trick:

var longString = "aaaaaaaaaaaaaaaaaaaa\
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

If backslash is the very last character before the line break than the
tokenizer will be happy.

Saves a hell of cycles (no runtime concatenation) - but "hacky" of
course.

[Richard Cornford]

Peter Michaux wrote:

VK wrote:

>Peter Michaux wrote:

>>Hi,

I'm thinking about code minimization. I can think of a
few places where whitespace matters

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new
line character matters.

Any others?

I guess Books of ECMA, Book of Tokens is the first place to
look for (ECMAScript 3rd ed., sec.7, "Lexical Conventions")

Besides that there is one cross-browser exception to add,
but the book above first.

What is the exception?

Haven't you understood yet that VK has no understanding of javascript
and so does not know what is supposed to happen and what is not?
Whatever answer he gives you (if any) it is either going to be one of
his misunderstandings, or it will be total irrelevant to the subject of
determining which whitespace can safely be removed from javascript
source code.

It must also be worth pointing out that the more you encourage VK to
post (which is what you have just done) the more he will act to squander
the resources of the group in correcting his nonsense. Which will have
the consequence of denying you the time of the people who could
otherwise maybe usefully respond to your questions.

Richard.

[Dr J R Stockton]

In comp.lang.javascript message <en*******************@news.demon.co.uk>
, Mon, 8 Jan 2007 23:11:39, Richard Cornford
<Ri*****@litotes.demon.co.ukposted:

>It must also be worth pointing out that the more you encourage VK to
post (which is what you have just done) the more he will act to squander
the resources of the group in correcting his nonsense. Which will have
the consequence of denying you the time of the people who could
otherwise maybe usefully respond to your questions.

It's a pity that you did not realise that earlier, while you were
responsible for maintaining the newsgroup FAQ.

ISTM that Randy may be heading in the same direction, although he has
not yet got unduly far along it.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[VK]

Peter Michaux wrote:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

a + ++b
a++ + b
a - --b
a-- -b
when a line ends without a semi-colon in which case the new line
character matters.

Any others?

------------------
------------------

I guess Books of ECMA, Book of Tokens is the first place to look for
(ECMAScript 3rd ed., sec.7, "Lexical Conventions")

Besides that there is one cross-browser exception to add, but the book
above first.

------------------
------------------

You are free to disregard, because it is not officially required by
specs, just an exploit of the internal tokenizer mechanics. Yet if it's
for public use - they you may account it as well. Any way, for long
string literals (too long to place on one line) instead of
concatenation one uses sometimes backslash trick:

var longString = "aaaaaaaaaaaaaaaaaaaa\
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

------------------
------------------
Cornford's bias:

Haven't you understood yet that VK has no understanding of javascript
and so does not know what is supposed to happen and what is not?
Whatever answer he gives you (if any) it is either going to be one of
his misunderstandings, or it will be total irrelevant to the subject of
determining which whitespace can safely be removed from javascript
source code.

It must also be worth pointing out that the more you encourage VK to
post (which is what you have just done) the more he will act to squander
the resources of the group in correcting his nonsense. Which will have
the consequence of denying you the time of the people who could
otherwise maybe usefully respond to your questions.

Now whould you mind to point a single reason of your regular furious
bias in this particular case. OT? Wrong data? Bad breakfast? The last
option seems as the only one suitable.

[Peter Michaux]

VK wrote:

Peter Michaux wrote:

Hi,

I'm thinking about code minimization. I can think of a few places where
whitespace matters

You are free to disregard, because it is not officially required by
specs, just an exploit of the internal tokenizer mechanics. Yet if it's
for public use - they you may account it as well. Any way, for long
string literals (too long to place on one line) instead of
concatenation one uses sometimes backslash trick:

var longString = "aaaaaaaaaaaaaaaaaaaa\
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

I have seen this slash at the end of the line but have never used it
myself because I haven't verified it's validity. Good to know that it
is something to be careful about before using or completely avoiding.
Thanks.

Peter

[Richard Cornford]

Peter Michaux wrote:

VK wrote:

<snip>

>var longString = "aaaaaaaaaaaaaaaaaaaa\
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

I have seen this slash at the end of the line but have never used it
myself because I haven't verified it's validity.

It is not valid at all. The tokenising/syntax rules for ECMAScript
explicitly forbid line terminator characters from appearing inside
string and regular expression literals. Using this half--ass hack
results in code that should not be expected to work anywhere and the
observation that it can work in two or three environments should not
bring the expectation that it would work in any others (and certainly
not all).

Good to know that it is something to be careful about
before using or completely avoiding.

It is not something to be careful about, as it should never be done in
the first place.

I did tell you that VK would either be wrong or be irrelevant. This
time he went for irrelevant.

Thanks.

Noted.

Richard.

[Dr J R Stockton]

In comp.lang.javascript message <11*********************@k58g2000hse.goo
glegroups.com>, Wed, 10 Jan 2007 23:20:55, Peter Michaux
<pe**********@gmail.composted:

>>
var longString = "aaaaaaaaaaaaaaaaaaaa\
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

I have seen this slash at the end of the line but have never used it
myself because I haven't verified it's validity. Good to know that it
is something to be careful about before using or completely avoiding.

It is something which should be known about.

RC, for instance, tends to express things purely from the point of view
of an *author*. A pure author does not need to know of such
continuation (though it could be useful in an internal test hack, where
known to work).

However, since it works in strings in IE, a *reader* of code may come
across it - and should understand its browser-dependent implications.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Plaintext, quoting : see <URL:http://www.usenet.org.uk/ukpost.html>
Do not Mail News to me. Before a reply, quote with ">" or "" (SoRFC1036)

[VK]

var longString = "aaaaaaaaaaaaaaaaaaaa\

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

I have seen this slash at the end of the line but have never used it
myself because I haven't verified it's validity.

It is not valid at all. The tokenising/syntax rules for ECMAScript
explicitly forbid line terminator characters from appearing inside
string and regular expression literals. Using this half--ass hack
results in code that should not be expected to work anywhere and the
observation that it can work in two or three environments should not
bring the expectation that it would work in any others (and certainly
not all).

As I pointed earlier, this is not an exploit of a particular bug on a
particular platform. This is an exploit of the core mechanics of any
ECMAScript-compliant code parser. The curious ones may read through the
section 7 of ECMAScript 3rd ed.
This way any ECMAScript-compliant parser will demonstrate this behavior
- or it is not ECMAScript-compliant. This is why "backslashed strings"
are equally supported by say IE, Firefox, Opera and by going back in
the history by Netscape 4.x, 3.x and 2.x

Respectively "supported" is not really a correct term as there is not
an extra feature to support here. "Vulnerable" would be more correct by
too scary sounding :-)

It also mean that the "hack" term is not fully applicable here. It is
no more hack then say return some other object from the constructor
instead of [this] or placing anonymous function expression as with()
argument. "Exploitation of mal-documented engine features" is more
suitable.

I am not propagandizing backslashed strings usage. I just want to make
clear the nature of this phenomenon, because in a few follow up posts
it was implicitly suggested that it is some IE/JScript-only bug, like
"since it works in strings in IE".
It "works" for all existing/ever existed UAs with javascript
support.

[Duncan Booth]

"VK" <sc**********@yahoo.comwrote:

As I pointed earlier, this is not an exploit of a particular bug on a
particular platform. This is an exploit of the core mechanics of any
ECMAScript-compliant code parser. The curious ones may read through the
section 7 of ECMAScript 3rd ed.
This way any ECMAScript-compliant parser will demonstrate this behavior
- or it is not ECMAScript-compliant. This is why "backslashed strings"
are equally supported by say IE, Firefox, Opera and by going back in
the history by Netscape 4.x, 3.x and 2.x

Please quote the exact part of section 7 which backs up your claim. This is
important because otherwise the existence in section 7 of text such as "A
'LineTerminator' character cannot appear in a string literal, even if
preceded by a backslash \." might lead some people to doubt your veracity.

[VK]

As I pointed earlier, this is not an exploit of a particular bug on a

particular platform. This is an exploit of the core mechanics of any
ECMAScript-compliant code parser. The curious ones may read through the
section 7 of ECMAScript 3rd ed.
This way any ECMAScript-compliant parser will demonstrate this behavior
- or it is not ECMAScript-compliant. This is why "backslashed strings"
are equally supported by say IE, Firefox, Opera and by going back in
the history by Netscape 4.x, 3.x and 2.x

Please quote the exact part of section 7 which backs up your claim.

The claim of "backslashed string" supported by all browsers cannot be
proved by quoting Books Of ECMA. It has to be proved by testing.
Either provide a browser where it fails, or let's agree on this
starting point. Then we can advance further by looking what specs
contradiction made it possible.

P.S. If you want to make historical researches as well, Netscape 4.x
can be downloaded at
<http://browser.netscape.com/ns8/download/archive.jsp>

[Duncan Booth]

"VK" <sc**********@yahoo.comwrote:

As I pointed earlier, this is not an exploit of a particular bug on
a particular platform. This is an exploit of the core mechanics of
any ECMAScript-compliant code parser. The curious ones may read
through the section 7 of ECMAScript 3rd ed.
This way any ECMAScript-compliant parser will demonstrate this
behavior - or it is not ECMAScript-compliant. This is why
"backslashed strings" are equally supported by say IE, Firefox,
Opera and by going back in the history by Netscape 4.x, 3.x and 2.x

Please quote the exact part of section 7 which backs up your claim.

The claim of "backslashed string" supported by all browsers cannot be
proved by quoting Books Of ECMA. It has to be proved by testing.
Either provide a browser where it fails, or let's agree on this
starting point. Then we can advance further by looking what specs
contradiction made it possible.

P.S. If you want to make historical researches as well, Netscape 4.x
can be downloaded at
<http://browser.netscape.com/ns8/download/archive.jsp>

That wasn't my point. My point was that you said it was "an exploit of
the core mechanics of any ECMAScript-compliant code parser" and that "The
curious ones may read through the section 7 of ECMAScript 3rd ed." but that
I read section 7 and it seems to say the opposite of what you claimed.

I asked you to back up your claim by being more specific about which part
of section 7 supported your viewpoint.

[Randy Webb]

VK said the following on 1/12/2007 9:00 AM:

>>As I pointed earlier, this is not an exploit of a particular bug on a
particular platform. This is an exploit of the core mechanics of any
ECMAScript-compliant code parser. The curious ones may read through the
section 7 of ECMAScript 3rd ed.

<snip>

>Please quote the exact part of section 7 which backs up your claim.

The claim of "backslashed string" supported by all browsers cannot be
proved by quoting Books Of ECMA.

That wasn't what was asked. You were being asked to please quote the
part of Section 7 that backs up your claim that it is an "exploit of the
core mechanics of any ECMAScript-compliant code parser". You then
pointed people to read Section 7. Now that you are being challenged to
back up that assertion you are finally admitting that nothing in Section
7 backs up your claim?

Besides, how you can claim it is some kind of "ECMAScript code parser"
issue and then tell people they can download NN4 to test it is, well,
ignorantly bliss at best as NN4 was almost at the end of its line before
the current edition of ECMAScript was released.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

That wasn't my point.

In this case you should quote more accurately the statements you are
referring to. In the post I answered to that was:

<snip>

This is why "backslashed strings"
are equally supported by say IE, Firefox, Opera and by going back in
the history by Netscape 4.x, 3.x and 2.x

Please quote the exact part of section 7 which backs up your claim.

Respectively I took "backs up your claim" as referring to the statement
right above your text, not the one at the beginning or middle of the
quoted block. And for the last statement about the universal
backslashed strings support - quoting ECMAScript specs is indeed
pointless.

As I have some experience in clj discussion specifics :-), you will not
go so easy by putting the opponent into defense position.
So far other people made statements which are not supported by any
facts: namely that backslashed strings are supported by IE only or "by
two or three browsers".
I say that it is supported by all existing/ ever existed browsers and
this statement is rather easy to check. So first we dismiss the false
statement of a narrow support of such strings - or someone will point
an actual browser w/o such support. One step at one time, OK? And on
the current step _I_ have nothing to prove: whoever believes it may
fail somewhere let them search for such browser. Or simply admit:
- Yes, you are correct, backslashed strings are supported on all
current and historical UAs.

Then it will be the time to read the specs.

[Duncan Booth]

"VK" <sc**********@yahoo.comwrote:

As I have some experience in clj discussion specifics :-), you will not
go so easy by putting the opponent into defense position.

Oh, so you're an opponent are you? Sorry, my mistake, I hadn't realised I
was fighting you.

I read the section of the spec that you sent me to and it seemed to
contradict you. I know though that the ecmascript spec can be very
confusing, so I simply asked you to clarify what you had said. I could
have interpreted it incorrectly: I have done in the past and no doubt will
again in the future. It was a request for information.

So far other people made statements which are not supported by any
facts: namely that backslashed strings are supported by IE only or "by
two or three browsers".

Irrelevant. Have that discussion with the people who are making those
statements. I'm just trying to ask a polite question.

[Richard Cornford]

VK wrote:

>>>var longString = "aaaaaaaaaaaaaaaaaaaa\
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\
cccccccccccccccccccccccccccccccccc"

I have seen this slash at the end of the line but have never
used it myself because I haven't verified it's validity.

It is not valid at all. The tokenising/syntax rules for ECMAScript
explicitly forbid line terminator characters from appearing inside
string and regular expression literals. Using this half-ass hack
results in code that should not be expected to work anywhere and
the observation that it can work in two or three environments
should not bring the expectation that it would work in any others
(and certainly not all).

As I pointed earlier, this is not an exploit of a particular bug
on a particular platform. This is an exploit of the core mechanics
of any ECMAScript-compliant code parser.

Nonsense. It relies entirely on a script parser electing not to impose
the syntax rules as specified in ECMA 262.

The curious ones may read through
the section 7 of ECMAScript 3rd ed.

And they easily may understand it better then you do. for example, where
ECMA 262 first edition says:-

Note that 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.

- the second edition says:-

Note that 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.

- and the third, and current, edition says:-

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.

- they may realise that like terminators are _explicitly_ forbidden form
appearing in a string literal, even when preceded by a backslash
character.

This way any ECMAScript-compliant parser will demonstrate
this behavior - or it is not ECMAScript-compliant.

Nonsense. This cannot be expected to work in any ECMA 262 compliant
script engine.

This is why "backslashed strings" are equally supported by say
IE, Firefox, Opera and by going back in the history by Netscape
4.x, 3.x and 2.x

That is just 3 script environments.

Respectively "supported" is not really a correct term as there
is not an extra feature to support here. "Vulnerable" would be
more correct by too scary sounding :-)

You have never been qualified to judge.

It also mean that the "hack" term is not fully applicable here.

Why not? When a construct cannot be expected to work at all using it
because it has been observed to work in some environments is a "hack".

It is no more hack then say return some other object from
the constructor instead of [this] or placing anonymous function
expression as with() argument. "Exploitation of mal-documented
engine features" is more suitable.

You just don't understand the specification, so you cannot judge what is
"mal-documented" and what is not. However, the note about line
terminators in string literals seems fairly unambiguous to me.

I am not propagandizing backslashed strings usage.

You are suggesting that it is a credible subject for consideration, when
it is something that should never have been expected to work, and so
should never have been attempted in a general context.

I just want to make clear the nature of this phenomenon,

You have already miss-attributed it.

because in a few follow up posts it was implicitly suggested
that it is some IE/JScript-only bug,

Not in my experience.

like "since it works in strings in IE".
It "works" for all existing/ever existed UAs with javascript
support.

It does not work in the NetFront browser, to name just one (and one is
sufficient to prove the assertion "It "works" for all existing/ever
existed UAs with javascript support" as being false). NetFront claims to
have an ECMA 262, 3rd Ed. compliant script engine, and its regarding an
ECMAScript syntax error as a syntax error does not contradict that.

Richard.

[Ray]

VK wrote:

As I pointed earlier, this is not an exploit of a particular bug on a
particular platform. This is an exploit of the core mechanics of any
ECMAScript-compliant code parser. The curious ones may read through the
section 7 of ECMAScript 3rd ed.

Did you actually read the spec itself? I did. It says on page 20: "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."

You can download the 3rd edition here:
http://www.ecma-international.org/pu...T/Ecma-262.pdf

This way any ECMAScript-compliant parser will demonstrate this behavior
- or it is not ECMAScript-compliant.

Nah, that's just plain wrong. See the document again.

http://www.ecma-international.org/pu...T/Ecma-262.pdf

Cheers
Ray

[John G Harris]

In article <eo*******************@news.demon.co.uk>, Richard Cornford
<Ri*****@litotes.demon.co.ukwrites

<snip>

>- and the third, and current, edition says:-

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.

<snip>

The <backslash><line endconvention is needed by C macros. Once some
fool put it into a browser it became extremely difficult to take it out
again.

Sorry for the interruption :-)

John
--
John Harris

[VK]

Oh, so you're an opponent are you? Sorry, my mistake, I hadn't realised I

was fighting you.

Possibly previous clj discussions made me overly defensive. Sorry then.

I read the section of the spec that you sent me to and it seemed to
contradict you. I know though that the ecmascript spec can be very
confusing, so I simply asked you to clarify what you had said. I could
have interpreted it incorrectly: I have done in the past and no doubt will
again in the future. It was a request for information.

I am not sure anymore myself if I have interpreted it correctly: I have
done mistakes in the past and no doubt will again in the future :-)
:-|

That would help to understand the exact meaning of "white space"
(a.k.a. whitespace) term in ECMAScript: _not_ that one from written
definitions and comments, but that one resulting from the formal
algorithms provided in specs.

P.S.
"JavaScript Language Specification : Preliminary Draft"
Brendan Eich
C. Rand Mckinney
11/18/96
"White space is defined as the ASCII space, horizontal tab, and form
feed characters, as well as line terminators."

ECMAScript 3rd ed.:
"The source text of an ECMAScript program is first converted into a
sequence of input elements, which are either tokens, line terminators,
comments, or white space."

Unicode, Inc.:
"There are other characters that have no visible glyphs: the whitespace
characters. These typically have advance-width, however. The line
separation characters such as CR do not clearly exhibit this
advance-width because they are always at the end of a line, but most
GUIs show a visible advance width when selected."

And the sh** like that all across the Internet. If you still keep some
idea of what whitespace is as such, and what is it in javascript and
what is it in javascript output to HTML parser - then you are lucky and
I'm not.