how window.location.href() works?

[omavideniz]

hi,
as i know href is a property of location but location.href(url) works
fine with IE 6. i couldn't figure out how its possible? is it a kind of
browser syntax-tolerance helping it to work? how the heck is this
working?
thanks

 

[VK]

as i know href is a property of location but location.href(url) works
fine with IE 6. i couldn't figure out how its possible? is it a kind of
browser syntax-tolerance helping it to work?

Yes it is. They just got pissed with the endless chain of users using
location.href as a method call and filing bugs to MSDN after that.
After the realisation that no one will ever read damn manuals anyway,
they just changed the property behavior, so now it can be used either
as property or as method. I wouldn't encourage anyone to use it, as
other UA producers so far have stronger nerves (or greater hope to
manuals)

how the heck is this working?

In the way it was internally programmed, what do you mean "how"? It is
their software, they could program it so location.href(null) would
start play country music - if they wanted to.

 

[Lee]

VK said:

Yes it is. They just got pissed with the endless chain of users using
location.href as a method call and filing bugs to MSDN after that.
After the realisation that no one will ever read damn manuals anyway,
they just changed the property behavior, so now it can be used either
as property or as method.

Another interpretation is that they saw an opportunity to take advantage
of inept programmers to gain market share. When a page works in IE but
not in Netscape (etc), the typical user sees IE as the superior browser.


--

 

[VK]

Another interpretation is that they saw an opportunity to take advantage
of inept programmers to gain market share. When a page works in IE but
not in Netscape (etc), the typical user sees IE as the superior browser.

Also possible
And other producers extended setAttribute functionality to make IE look
as a bad guy.
Cold War has its specifics...

 

[Michael Winter]

Another interpretation is that they [Microsoft] saw an opportunity
to take advantage of inept programmers to gain market share. When
a page works in IE but not in Netscape (etc), the typical user sees
IE as the superior browser.

Also possible And other producers extended setAttribute
functionality to make IE look as a bad guy. [...]

What are you babbling about now? Microsoft have extended the
setAttribute method; other vendors have not.

From MSDN:

Syntax
object.setAttribute(sName, vValue [, iFlags])

Parameters
sName Required. String that specifies the name of the
attribute.
vValue Required. Variant that specifies the string, number,
or Boolean to assign to the attribute.
iFlags Optional. Integer that specifies one the following
flags:
0 When the attribute is set, it overwrites any
attributes with the same name, regardless of
their case.
1 Default. The case of the attribute that you set
is respected when it is set on the object.

There are only two arguments to the method as specified by the W3C, and
both are strings. There's also the following sentence in the Remarks for
that same description:

When setting the CLASS attribute using this method, set the
sName to be "className", which is the corresponding Dynamic
HTML (DHTML) property.

which is patently bad behaviour.

Want further proof? The following snippet is a quick-and-dirty outline
of a simple test.

<input id="test" type="button" value="Test">

function listener() {
alert('Fired listener.');
}
listener.toString = function() {
return "alert('toString was used.');";
};

document.getElementById('test').setAttribute('onclick',
listener);

As the arguments to the setAttribute method are only strings, it is
reasonable to expect the host to coerce the value to a string. As a
result, the onclick attribute should be assigned the string,
"alert('toString was used.');". Clicking on the button may then either
do nothing, or display an alert (as it might were the value part of the
original markup).

You will find that indeed Opera and Firefox will call the toString
method and use its return value to set the attribute. Furthermore,
clicking the button will display an alert containing the string,
'toString was used.' MSIE, on the other hand, will display an alert
containing the value, 'Fired listener.'

True, if one were to replace the function reference assigned to listener
with a simple string, Firefox and Opera would treat that as code for an
event handler and IE would not. However, whilst not mandated, it is
sensible behaviour: a browser would do so if the attribute was present
in the markup, so why not here, too? Modifying other attributes would
affect the document in a similar way.

As is often the case, Microsoft are the bad/inept ones, and the others
are doing only what is correct or reasonable.

Mike

 

[VK]

What are you babbling about now?

(muttering, grumbling, grunting, murmuring, rumbling - for a variety in
the future use ;-)

Microsoft have extended the
setAttribute method; other vendors have not.

I was not talking about extra arguments in the method call. It was
about setting intrinsic event handler over setAttribute.

As the arguments to the setAttribute method are only strings, it is
reasonable to expect the host to coerce the value to a string. As a
result, the onclick attribute should be assigned the string,
"alert('toString was used.');". Clicking on the button may then either
do nothing, or display an alert (as it might were the value part of the
original markup).

That a discussion of a kind "if I put 220V instead of 120V, will it
explode right away, some later or will just give a smoke" The exact
kind of argument you have to use with setArgument (literal string) is
defined in DOM Core. It also defines pretty well what do you have to do
to serve something else rather than literal string.
<http://www.w3.org/TR/DOM-Level-2-Core/core.html>

To keep "high voltage" testing you also may play with the code at the
bottom of this post. Personally I don't see a reason to feed to some
method non-standard values just to see how will it react on that. Still
(as I already said in the previous post) I welcome any convenience and
screw on standards if they prevent that. Yet I would resist to any
attempt to represent setAttribute usage for setting event handlers as
some kind of "standard proper way".

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>setAttribute</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
color: #000000;
background-color: #FFFFFF;
}
</style>
<script type="text/javascript">

function myFunction() {
return 'value from myFunction';
}
myFunction.toString = function() {
alert('toString called');
return 'value from myFunction.toString';
}

function init() {
if ('undefined' == typeof p01) {
p01 = document.getElementById('p01');
}
with(p01.style) {
cursor = 'pointer';
textDecoration = 'underline';
color = '#0000FF';
}
p01.setAttribute('click',myFunction,0);
}

window.onload = init;
</script>
</head>
<body>
<p id="p01">No content</p>
<p onClick="alert(p01.getAttribute('click'))">Click me</p>
</body>
</html>

 

[Michael Winter]

(muttering, grumbling, grunting, murmuring, rumbling - for a variety
in the future use ;-)

It is not a laughing matter that you frequently write indecipherable
nonsense or, worse still, understandable nonsense that's simply wrong.

I was not talking about extra arguments in the method call. It was
about setting intrinsic event handler over setAttribute.

I'm not particularly interested in what you thought you were writing:
you made a statement, and it was false.

The exact kind of argument you have to use with setArgument (literal
string) is defined in DOM Core.

'Literal string'? Now what's that supposed to mean? A string is a
string. Are you perhaps making some kind of cryptic reference to the
note that character sequences that look like entity or character
references will not be treated as such?

[snip]

To keep "high voltage" testing you also may play with the code at the
bottom of this post. Personally I don't see a reason to feed to some
method non-standard values just to see how will it react on that.

I was making a point. You stated that "other producers extended
setAttribute functionality to make IE look as a bad guy", when in fact
it is Microsoft that have done so. There can be no more explicit proof
than the fact that IE will add a function to an element using the
setAttribute method, rather than taking the string representation of
that object.

[snip]

Mike

 

[VK]

'Literal string'? Now what's that supposed to mean?

literal text (string) - thus not resolved for internal entities (think
apos in Perl string)

Are you perhaps making some kind of cryptic reference to the
note that character sequences that look like entity or character
references will not be treated as such?

That's an adequate interpretation.

I was making a point. You stated that "other producers extended
setAttribute functionality to make IE look as a bad guy", when in fact
it is Microsoft that have done so. There can be no more explicit proof
than the fact that IE will add a function to an element using the
setAttribute method, rather than taking the string representation of
that object.

These are two completely different issues here: 1) documented behavior
testing and 2) build-in AID (Anti-Idiot Defence) testing: where the
letter I in AID doesn't offend anyone, just a slang term.

Say document background color has well defined set of values you are
allowed to use, and if one of allowed values doesn't lead to the
expected results, that's a bug. At the same time say <body
bgcolor="!FFFFFF"> makes screen kinda aqua color, and <body
bgcolor="!@#$%"> makes it black. It is maybe interesting to investigate
why it becomes black and not say green, or why it still becomes green
on the browser X, but black on browser Y. It may be interesting, but is
it really? The only important thing is that the AID is in action and
UA's do not crash on it.

The same with setAttribute: it is said what you can use it for and what
type of arguments you can use for it. JavaScript function reference is
not among of these values, so whatever it does - it does. AID is in
action, browser doesn't crash and you even have some more-or-less
resonable outcome. Maybe the outcome on the browser X seems more
convenient than on the browser Y: but it's again a discussion of what
color should be on value "!@#$%" : black or green.

 

[Michael Winter]

On 24/05/2006 13:21, VK wrote:

[snip]

The same with setAttribute: it is said what you can use it for and
what type of arguments you can use for it.

If you are aware of any feature in ECMAScript, it should be implicit
type conversion.

JavaScript function reference is not among of these values, so
whatever it does - it does.

As a native object, a function object will have a toString method. When
coerced into a string, this method will be called and the returned
string value will be used in place of the object.

As usual, it's all very predictable.

AID is in action, browser doesn't crash and you even have some
more-or-less resonable outcome.

Implicit type conversion is not a matter of defence against idiots
(though it may also have that effect), but a measure of convenience. If
I have an object that represents something, say a URI, I could write

element.setAttribute('href', uri.toString());

but

element.setAttribute('href', uri);

is so much nicer.

Maybe the outcome on the browser X seems more convenient than on the
browser Y: but it's again a discussion of what color should be on
value "!@#$%" : black or green.

That's error correction, and a completely different subject.

Mike

 

[VK]

Implicit type conversion is not a matter of defence against idiots
(though it may also have that effect), but a measure of convenience. If
I have an object that represents something, say a URI, I could write

element.setAttribute('href', uri.toString());

but

element.setAttribute('href', uri);

is so much nicer.

Agree, but you have to have then an overloaded toString method,
otherwise say function reference will return function body as string,
and a custom object string "[object]" or "Object [object]" (latter
varies on circumstances).

Yet it is pretty far of the issue of using setAttribute to assign an
executable JavaScript code to an intrinsic event handler. That one is
not supported by any specs, yet may be nice to have in some situations.

You raised my interest to this question so I spent some time trying to
figure out why "the screen gets black and not green" (see my previous
post

You can click "Click me" to see that the behaviour is consistent
between browsers including IE.

But let's make an intentional error in the second handler, let's change
onclick="alert(p.getAttribute('onclick'))"
to
onclick="alert(p.getAttribute('onclick')"
(parenthesis is missing)

You see that IE generates syntax error on page load. At the same time
Firefox doesn't care of it until you actually click the link. So IE
parses all intrinsic handlers on page load (just like any <script>
block), while Firefox and Co seem holding it as a plain text until call
and only then attempting to parse it. That is the core reason I guess
between "black screen and green screen" if I contunue the same analogy.

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function f() {
return "string from f()";
}
f.toString = function() {
return "string from f.toString()";
}

function demo() {
p = document.getElementById('p01');
p.setAttribute('onclick', f, 0);
}

window.onload = demo;
</script>
</head>

<body>
<p id="p01">Test paragraph</p>
<p style="cursorointer"
onclick="alert(p.getAttribute('onclick'))">Click me</p>
</body>
</html>