Opera javascript problem

[crater]

The following function is not updating an image in opera 9.02.

upd_on = new Image()
upd_on.src = "images/update_button.gif"
function enableUpdate() {
var update = document.getElementById("cart_Update")
update.disabled = ""
update.style.cursor = "pointer"
update.src = upd_on.src
}

<input type="image" id="cart_Update" src="images/
update_button_disabled.gif" name="cart_Update" value="Update"
disabled="disabled" />

The normally gray image should be replaced with a coloured image. This
works fine in IE and NN, just not in Opera.
The cursor changes, and that's CSS2. Why won't it update the image??

Anyone got any clues before I pull all my hair out?

 

[Martin Honnen]

var update = document.getElementById("cart_Update")
update.disabled = ""

update.disabled = false

 

[crater]

update.disabled = false

Yes, thanks, Martin.

Picky, though. One would think that "" is equivalent to false as it is
in all other browsers.

 

[John Postlethwait]

Yes, thanks, Martin.

Picky, though. One would think that "" is equivalent to false as it is
in all other browsers.

Opera actually has it right. In most languages an empty string ("") is
not a null or false value. Since it is a string, if even an empty one,
it is not a boolean false nor is it null. For instance in Ruby an
empty string will always come out as true.

A lot of browser will allow for incorrect values to be assigned and
still parse it just fine. In this case the disabled property is
supposed to take a boolean value, not a string, but using an empty
string apparently works in some browsers.

 

[dd]

Opera actually has it right. In most languages an empty string ("") is
not a null or false value. Since it is a string, if even an empty one,
it is not a boolean false nor is it null. For instance in Ruby an
empty string will always come out as true.

A lot of browser will allow for incorrect values to be assigned and
still parse it just fine. In this case the disabled property is
supposed to take a boolean value, not a string, but using an empty
string apparently works in some browsers.- Hide quoted text -

- Show quoted text -

Just because "most languages" consider an empty string ("") as true,
and Opera does that too, doesn't make it right. The specification of
JavaScript is what it is, and Opera should respect that if it expects
code written to conform with the language to work properly. JavaScript
has many "truthy" and "falsey" values, and an empty string is
considered falsey. The other browsers aren't just "allowing for
incorrect values", they're following the rules for JavaScript (even if
they're considered bugs, they're bugs that the language developers
have left in for backwards compatibility).

 

[VK]

Picky, though. One would think that "" is equivalent to false as it is
in all other browsers.

Following this logic you should also require the same result from

image.disabled = false;
image.disabled = "";
image.disabled = 0;
image.disabled = undefined;
image.disabled = null;

but I doubt it will work for many browsers, except "little durt" with
"" allowed on FF and IE

Overall empty string is not false and it has nothing to do with it -
no more than with 0. In javascript in _comparison operations_ empty
string is treated as false. It is also treated as false in Boolean
object production: both new Boolean("") and new Boolean(false) will
result in valueOf() == false
In assignments - especially in DOM interface assignments - false, "",
0, null and undefined are values by their own.

 

[John Postlethwait]

Just because "most languages" consider an empty string ("") as true,
and Opera does that too, doesn't make it right. The specification of
JavaScript is what it is, and Opera should respect that if it expects
code written to conform with the language to work properly. JavaScript
has many "truthy" and "falsey" values, and an empty string is
considered falsey. The other browsers aren't just "allowing for
incorrect values", they're following the rules for JavaScript (even if
they're considered bugs, they're bugs that the language developers
have left in for backwards compatibility).

You are correct, the specification is what it is and that is exactly
what I said it was.

From the ECMAScript Specification, page 30:

7.8.4 String Literals
A string literal is zero or more characters enclosed in single or
double quotes.

As you said, just because a browser does it differently doesn't make
it right. A zero character string is still a string, not a boolean.

 

[Richard Cornford]

7.8.4 String Literals
A string literal is zero or more characters enclosed in
single or double quotes.

As you said, just because a browser does it differently
doesn't make it right. A zero character string is still
a string, not a boolean.

It is in the nature of javascript that when a particular type is expected
(in some context) and another type is provided an implicit
type-conversation happens to provide the expected type from the provided
type.

Generally, when a DOM property has a defined type an assignment to that
property also implies a type-conversion from the provided type to the
desired (or an acceptable) type. Thus when assigning to a boolean
property and providing a string that string may be type-converted. And
that type-conversion will likely follow the normal javascript
type-conversion rules.

The type conversion rules for converting a string primitive to a boolean
primitive are that non-empty strings are boolean true and the empty
string is boolean false.

In javascript the 'trueness' of any value is usually judged by the
boolean primitive value that would result from applying the language's
type-conversation to boolean rules to the original value. Thus an empty
string is regarded as a 'false' value, while non-empty strings are true.

Richard.

 

[John Postlethwait]

It is in the nature of javascript that when a particular type is expected
(in some context) and another type is provided an implicit
type-conversation happens to provide the expected type from the provided
type.

Generally, when a DOM property has a defined type an assignment to that
property also implies a type-conversion from the provided type to the
desired (or an acceptable) type. Thus when assigning to a boolean
property and providing a string that string may be type-converted. And
that type-conversion will likely follow the normal javascript
type-conversion rules.

The type conversion rules for converting a string primitive to a boolean
primitive are that non-empty strings are boolean true and the empty
string is boolean false.

In javascript the 'trueness' of any value is usually judged by the
boolean primitive value that would result from applying the language's
type-conversation to boolean rules to the original value. Thus an empty
string is regarded as a 'false' value, while non-empty strings are true.

Richard.

Fair enough. I was aware that this was the case when using them in an
if statement, but not aware that it was the case for expected types
when assigning values to properties...

Do you happen to know if this is a part of the specification, or if
this is one of those grey areas that the parser developers have to
decide on?

 

[Richard Cornford]

On Mar 6, 3:30 pm, Richard Cornford wrote:

Fair enough. I was aware that this was the case when using them
in an if statement, but not aware that it was the case for
expected types when assigning values to properties...

It only really applies to assignment to the properties of host objects,
and arguments to host method calls.

Do you happen to know if this is a part of the specification,
or if this is one of those grey areas that the parser developers
have to decide on?

The specifications state what type properties of DOM objects have. That
implies that when you read them they should return the type that the
specification says they should have. In principle it should be possible
for the property to accept and store any type and the type-conversion to
happen at the point of reading the value, but it is probably easier to do
any required type-conversion at the point of assignment.

Richard.