Next: capture external js filename
From: Garrett Smith on 2 Feb 2010 16:54
Matt Kruse wrote:
> On Feb 2, 12:23 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
>> Therefore, the following should work with both implementations:
>> var myBigBlob = (<foo><![CDATA[
> Did you try it? It doesn't work.
A SyntaxError should be expected, right?
In Chrome I get the error:
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.
From: Thomas 'PointedEars' Lahn on 2 Feb 2010 17:16
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 184.108.40.206 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.
> 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?
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Lasse Reichstein Nielsen on 2 Feb 2010 17:28
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.
Lasse Reichstein Holst Nielsen
From: "Michael Haufe ("TNO")" on 2 Feb 2010 20:30
On Feb 2, 12:23 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> 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 2 Feb 2010 21:03
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 ...
> 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
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";
var str = "I am the closest thing\
to multi-line strings that we can get\
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.