Safari and JavaScript arrays

[Duderonomoy]

Hello,

I am querying the JavaScript community to learn if
others are having problems with Safari[1] and JavaScript
arrays:

myImages = [
"images/image0.jpg",
"images/image1.jpg",
"images/image2.jpg",
];

then referenced like this:

document.images[1].src = myImages[1];

Is this a known bug with Safari? Broken arrays?

(BTW the above works in every major browser's
recent version; those I have tried)

I can write a string literal into the src property:

document.images[1].src = "images/image1.jpg";

and achieve image replacement, but not when the string
literal is referenced from an array.

What gives? Am I doing something Really Stupid (TM)?

Thanks in advance for advice.

Cheers,
DK

[1] Referring to Safari version 1.0.1

[Jeff Thies]

> I am querying the JavaScript community to learn if

others are having problems with Safari[1] and JavaScript
arrays:

myImages = [
"images/image0.jpg",
"images/image1.jpg",
"images/image2.jpg",
];
Hmmm. There's line breaks in there. Try it on one line.

Near as I can tell tell Safari handles arrays the same as othres. At least I
haven't seen problems.

Jeff


then referenced like this:

document.images[1].src = myImages[1];

Is this a known bug with Safari? Broken arrays?

(BTW the above works in every major browser's
recent version; those I have tried)

I can write a string literal into the src property:

document.images[1].src = "images/image1.jpg";

and achieve image replacement, but not when the string
literal is referenced from an array.

What gives? Am I doing something Really Stupid (TM)?

Thanks in advance for advice.

Cheers,
DK

[1] Referring to Safari version 1.0.1

[Duderonomoy]

This was a weird one...

Here's the bottom line:

Be careful to not use the same names in varible namespace and
selector namespace on Safari version <= 1.2.1 (125.1).

I was doing something like this:

document.getEle mentById("myIma ge").src = myImage[index];

where I had an array of strings labelled "myImage" and
and id selector in the HTML called "myImage".

When the JavaScript array name was modifed so that it would
not clash with the id selector, Safari worked properly.

So, my way of fixing it was simply to the change my array name
to "myImages" array.

Cheers,
DK

[Andrew Tetlaw]

Duderonomoy <Se*@reply.to > wrote in message news:<pa******* *************** ******@reply.to >...

where I had an array of strings labelled "myImage" and
and id selector in the HTML called "myImage".

When the JavaScript array name was modifed so that it would
not clash with the id selector, Safari worked properly.

Does it have the same behaviour as IE then. You can refer to a page
element in javascript by its id attribute value? For example if you
have

[xml id="xmlData"][/xml]

In javascript you can refer to it like this:

xmlData.src = '/xml/data.xml';

If so that'd be the cause of the clash.

[Michael Winter]

On Sat, 24 Apr 2004 06:27:20 GMT, Duderonomoy <Se*@reply.to > wrote:

[snip]

I was doing something like this:

document.getEle mentById("myIma ge").src = myImage[index];

where I had an array of strings labelled "myImage" and
and id selector in the HTML called "myImage".

When the JavaScript array name was modifed so that it would
not clash with the id selector, Safari worked properly.

So, my way of fixing it was simply to the change my array name
to "myImages" array.

How did you declare the identifier? In IE, using the var keyword overrides
document globals for that scope (IDs and the like).

Mike

--
Michael Winter
M.******@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Duderonomy]

On Sun, 25 Apr 2004 00:20:27 +0000, Michael Winter wrote:

On Sat, 24 Apr 2004 06:27:20 GMT, Duderonomoy <Se*@reply.to > wrote:

[snip]

I was doing something like this:

document.getEle mentById("myIma ge").src = myImage[index];

where I had an array of strings labelled "myImage" and
and id selector in the HTML called "myImage".

When the JavaScript array name was modifed so that it would
not clash with the id selector, Safari worked properly.

So, my way of fixing it was simply to the change my array name
to "myImages" array.

How did you declare the identifier? In IE, using the var keyword overrides
document globals for that scope (IDs and the like).

Mike

Thanks for the reflective surface :)

Hmmm. I am not sure of the ramifications of what you are indicating.
Though I am very interested. I assumed such symbolic names would be
in different name spaces.

I was declaring data like this, in a separate file:

var demoText = [
"string one",
"string two",
"string thr",
]

var demoImage = [
"string/path/one.jpg",
"string/path/two.jpg",
"string/path/thr.jpg",
]

In another file an event handler:

function ClickHandler (evt)
{
<snip>
document.getEle mentById("demoI mage").src = demoImage[idx];
document.getEle mentById("demoT ext").innerHTM L = demoText[idx];
<snip>
}

And finally the HTML file:

<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=ut f-8" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<script src="data.js"></script>
<script src="events.js" ></script>
</head>

<body>
<img id="demoImage" src="">
<p id="demoText">b lah</p>
</body>
</html>

Cheers,
DK

[Richard Cornford]

Duderonomy wrote:
<snip>

I was declaring data like this, in a separate file:

var demoText = [
"string one",
"string two",
"string thr", ^ ]

var demoImage = [
"string/path/one.jpg",
"string/path/two.jpg",
"string/path/thr.jpg", ^ ]

<snip>

A running theme in your Array literal definitions is a final Elison,
which is allowed but is known to be inconstantly handled across
browsers. ECMA 262 would require the resulting Array to be 4 elements
long with the first three elements containing strings and the fourth
element undefined. There doesn't seem to be any good reason for creating
Arrays that are longer than the number of string literals they contain
and any looping up to demoText.length , for example, may result in the
final undefined element being used (with potentially error-producing
results).

Richard.

[Lasse Reichstein Nielsen]

"Richard Cornford" <Ri*****@litote s.demon.co.uk> writes:

[Array written ["a","b","c" ,]...]

A running theme in your Array literal definitions is a final Elison,
which is allowed but is known to be inconstantly handled across
browsers. ECMA 262 would require the resulting Array to be 4 elements
long with the first three elements containing strings and the fourth
element undefined.

No, ECMA 262 v3 (haven't checked earlier versions) would required the
array to have length 3.

The relevant rule of 11.1.4 is
ArrayLiteral : [ ElementList , Elision_opt ]
where ElementList matches the three strings separated by commas,
and Elision_opt is empty.

If you check the evaluation of this rule
---
The production ArrayLiteral : [ ElementList , Elisionopt ] is
evaluated as follows:
1. Evaluate ElementList.
2. Evaluate Elision; if not present, use the numeric value zero.
3. Call the [[Get]] method of Result(1) with argument "length".
4. Call the [[Put]] method of Result(1) with arguments "length" and
(Result(2)+Resu lt(3)).
5. Return Result(1).
---
the ElementList evaluates to the array ["a","b","c"]. The rule for
ArrayLitreals increases the length of this array with the size of the
(empty) Elision (it specifically says to use zero if the elision is
omitted). It does not include the litreal comma of the rule in this
count.

I believe this rule is deliberate, attempting to mimic Java's
literal array notation, where a final comma is allowed.

However, IE 6 still fails to implement this correctly, and thinks
["a",].length == 2, so there is reason to omit the unnecessary comma.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

Lasse Reichstein Nielsen wrote:

"Richard Cornford" <Ri*****@litote s.demon.co.uk> writes:

[Array written ["a","b","c" ,]...]

A running theme in your Array literal definitions is a final Elison,
which is allowed but is known to be inconstantly handled across
browsers. ECMA 262 would require the resulting Array to be 4 elements
long with the first three elements containing strings and the fourth
element undefined.
No, ECMA 262 v3 (haven't checked earlier versions) would required the
array to have length 3.

The relevant rule of 11.1.4 is
ArrayLiteral : [ ElementList , Elision_opt ]
where ElementList matches the three strings separated by commas,
and Elision_opt is empty.

If you check the evaluation of this rule
---
The production ArrayLiteral : [ ElementList , Elisionopt ] is
evaluated as follows:
1. Evaluate ElementList.
2. Evaluate Elision; if not present, use the numeric value zero.
3. Call the [[Get]] method of Result(1) with argument "length".
4. Call the [[Put]] method of Result(1) with arguments "length" and
(Result(2)+Resu lt(3)).
5. Return Result(1).
---
the ElementList evaluates to the array ["a","b","c"]. The rule for
ArrayLitreals increases the length of this array with the size of the
(empty) Elision (it specifically says to use zero if the elision is
omitted). It does not include the litreal comma of the rule in this
count.

It comes down to that separating comma in the ArrayLiteral production,
is it an Elison itself or just a separator of the ElementList from any
following optional Elison? Reviewing the production rules with the comma
in that rule highlighted I tend to agree with you that an isolated
trailing comma should not make the Array any longer than the
ElementList.

I seem to remember having this discussion with you before, your
conclusion didn't stick in my memory because I prefer to deal with the
issue by avoiding even attempting to defined sparse arrays, and never
include trailing commas.
I believe this rule is deliberate, attempting to mimic Java's
literal array notation, where a final comma is allowed.

However, IE 6 still fails to implement this correctly, and thinks
["a",].length == 2, so there is reason to omit the unnecessary comma.

There is no question that this is an area of inconsistent
implementations that is best avoided entirly.

Richard.

[Duderonomy]

On Sun, 25 Apr 2004 14:40:12 +0100, Richard Cornford wrote:

Duderonomy wrote:
<snip>

I was declaring data like this, in a separate file:

var demoText = [
"string one",
"string two",
"string thr", ^

]

A running theme in your Array literal definitions is a final Elison,
which is allowed but is known to be inconstantly handled across
browsers. ECMA 262 would require the resulting Array to be 4 elements
long with the first three elements containing strings and the fourth
element undefined. There doesn't seem to be any good reason for creating
Arrays that are longer than the number of string literals they contain
and any looping up to demoText.length , for example, may result in the
final undefined element being used (with potentially error-producing
results).

Richard.

Thanks for that feedback. It prompted me to make two version of my data
file, both with and without the trailing Elision. After testing it is
clear that such an issue was not causing the problem. Regardless, I will
not be inserting the Elision at the end of such definitions any more... I
never did that any other languages; so why start now. :)

Also, my code does not iterate across the array... Hence I would not
encounter this issue of a potentially undefined value.

Ultimately, the index, idx, is generated by an 'id' selector value of a
unique menu item; in my case, a Handler is tied to the onClick property of
a series of LI boxes that serve as menu items. So, when a menu item box is
clicked, an integer index value is derived from a unique id selector value
specified as an attribute of every LI element.

Thanks for the excellent feedback everyone... :)
I certainly know more stuff than before I asked you folks about this...

I submitted this issue as a bug against Safari. I'll follow-up here with
Apple's response.

Cheers,
DK