From: Garrett Smith on
Matt Kruse wrote:
> On Feb 2, 12:23 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> wrote:

[snip]

>
>> Therefore, the following should work with both implementations:
>> var myBigBlob = (<foo><![CDATA[
>> ...
>> ]]></foo>).toString();
>
> Did you try it? It doesn't work.
>

A SyntaxError should be expected, right?

In Chrome I get the error:
Refused to execute a JavaScript script. Source code of script found
within request.

Tracemonkey/Spidermonkey parses the XML and executes the code. It fails
to correctly produce a syntax error, as specified in Ecma-357, and fails
on that account.

http://code.google.com/p/chromium/issues/detail?id=30975
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on
Lasse Reichstein Nielsen wrote:

> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes:
>> Then I am at a loss to explain why it breaks in Chrome, unless V8 would
>> not support E4X.
>
> It doesn't.

I have since found a Chrome 4.0.249.43 package for Debian and can confirm
it for its V8.

> Nor does SquirrelFish, Trident or Carakan (so far).

By contrast, Trident is not a script engine. But JScript 5.x does not
support E4X, indeed.

> E4X is, afaik, only implemented by Mozilla and Adobe.

ACK

> And XML sucks, so I hope it stays that way! :)
>
> /L 'If you are writing XML by hand, you are doing something wrong!'

You are joking, right?


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Lasse Reichstein Nielsen on
Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes:

> Lasse Reichstein Nielsen wrote:

> By contrast, Trident is not a script engine. But JScript 5.x does not
> support E4X, indeed.

Ah, yes. JScript ofcourse.

>> /L 'If you are writing XML by hand, you are doing something wrong!'
>
> You are joking, right?

No, not really.
XML is needlessly verbose and yet not very readable. It's fine for
interoperability between systems, as a serialization format for
structured data. It's the least common denominator of structured
serialization formats. But writing it by hand, or even just editing,
should only be done for debugging purposes. At all other times, use
an editor that actually understands the data being edited, and create
the XML from that.
And that's just for plain XML. If it has to match a schema too, it
just got even easier to make an editing mistake.

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: "Michael Haufe ("TNO")" on
On Feb 2, 12:23 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:

> The syntax you have used to date apparently makes use of a bug in Gecko's
> ECMAScript for XML (E4X, ECMA-357) implementation.  V8 breaks on this
> syntax because syntactically valid ECMAScript for XML is expected, and `<>'
> is not well-formed XML:

"<>"..."</>" is an XMLList initializer described under ECMA-357
section 11.1.5, so I don't see how its a bug.
From: Stefan Weiss on
On 02/02/10 16:47, Matt Kruse wrote:
> In my Greasemonkey code written specifically for Firefox, I use this
> "heredoc" syntax a lot:
>
> var myBigBlob = (<><![CDATA[
>
> ... insert a bunch of free-form text here ...
>
> ]]></>).toString();
>
> Now that Chrome offers built-in Greasemonkey support, I'd like to
> support it as well, but it breaks on this syntax.
>
> Does anyone know of a better method that will work in both browsers?

Sorry, I don't. I've always wondered why multi-line string literals
aren't possible in JavaScript. AFAICS, there's nothing ambiguous about
this syntax:

var heredoc = "I am a multi-line
string; I end when the tokenizer
sees a double quote";

This is standard practice in many other programming languages. Maybe ES4
had something like this in the queue, but with ES5 geared towards
backwards compatibility, we probably won't see it for a long time.

The two usual workarounds are

var str = "I wish\n"
+ "I was\n"
+ "a multi-line string";

and

var str = "I am the closest thing\
to multi-line strings that we can get\
with JavaScript";

I don't know how well supported the second version is. At least the
first version will can optimized into a single string when it's
processed with a minimizer.


--
stefan