RobG wrote:
Michael Winter wrote:
<snip>
You could save the form element reference. As an intrinsic
event attribute is an anonymous function, variables declared
with var will be local just as in other contexts.
Which translates (I think) into:
the onclick could be written more concisely as:
onclick="A1.value=formatNum(A1);">
And to preempt questions on why I pass the reference to the
text box and not its value, it's because I felt like it. To
trim the code even further, the value can be passed so that
the onclick becomes:
onclick="A1.value=formatNum(A1.value);">
<snip>
If the intention here is to exchange the property accessor -
this.form.A1 - (better as this.form.elements.A1) for the identifier -
A1 -, then that is a risky practice as it requires that the reference to
the form element be available as a named property of an object on the
scope chain of the browser-constructed anonymous event handling
function.
As the global object is always on a function's scope chain all of the
browsers that make references to named form elements into named
properties of the global object will be able to pick up that reference.
Unfortunately, (or perhaps fortunately, as stuffing things into the
global namespace at the drop of a hat is not really a good idea) some
browsers just don't facilitate that (and more so with named elements
than IDed elements).
Some browsers do, however, generate a custom scope chain for their
attribute originating, internally generated event handling functions.
The process can be conceived as like wrapping the code provided for the
HTML attribute in a stack of - with - statements:-
onclick="A1.value=formatNum(A1);"
- becomes (like):-
function(e){
with(this){
with(this.form){
with(document){
A1.value=formatNum(A1);
}
}
}
}
Where the exact list of objects added to the scope chain varies
depending on the browser and the context of the element for which the
event handling method is created. The possibilities range form browsers
that provide no custom scope chain at all (Opera <= 6 being one
example), to browsers that will, in some contexts, pace every ancestor
of the element in the DOM on the scope chain (Mozilla/Gecko).
Unqualified - A1 - is resolved on the scope chain above as a named
property of the FORM element on the scope chain, *if* the browser has
paced the form on the scope chain. As it is known that some browsers do
not augment the scope chain of internally generated event-handling
functions at all, cross-browser scripting requires that code provided
for event handling attributes be written as if the only candidates for
the resolution of unqualified identifier on the scope chain were the
local "Variable" object (at the top of the chain, holding function local
variables and formal parameters ("event"?)), and the global object. Any
reliance on picking up, for example, a named form element as a named
property of the containing form using its name as an unqualified
identifier, will guarantee needless (avoidable) failure on some
browsers.
Incidentally, when I say that the scope chain augmentation is only like
wrapping the function body in a stack of - with - statements I am
observing an oddity of the behaviour of IE. If - with -, or any
mechanism that had a similar effect, was used, moving the event handler
to a different element would leave the scope chain used in the
resolution of identifiers unchanged. And this is indeed what happens on
Mozilla and Opera 7. On IE, if you move an internally generated event
handling function to a different element it gets a scope chain, when
executed, related to its new context of execution. The IE scope chains
are dynamic and created at the point of either assignment or execution.
(and calling one of these function directly as a function (instead of as
a method of an element) produces some very ECMAScript unlike behaviour
in identifier resolution). Of course moving internally generated event
handling functions is extremely unlikely to be something anyone want to
do (beyond experimenting with the subject).
Richard.
