Isaac said:
That's a good point in general, but it's not an all-or-nothing
thing. In this case, the browsers that do not accept a function
object as the first argument to setTimeout are very rare and
outdated.
Are they? (beyond the observation that anything that is not IE 6 may be
called 'vary rare' by the numbers)
Clean degradation is a valid concern, of course, but there's
a trade-off here.
A trade-off? Knowing that there are no - setTimeout - implementations
that do not function with a string as the first argument you are
recommending a blanket adoption of the exclusive use of function
references and then saying that there is a trade-off around the
additional effort required to handle the consequential drop in
cross-browser compatibility that will follow?
setTimeout and setInterval perform better with a function
pointer,
Function reference. There is no concept of "pointer" in javascript.
and this only causes a problem in browsers that are 3-4
versions out of date, and used by a vanishingly small
minority of users.
3-4 versions? How are you counting "versions" here? Konqueror 2 did not
support function references are arguments to setTiemout, but its current
version is 3 (maybe 4 at a pinch). And the "small minority of users"
argument goes straight back to justifying IE 6 only websites.
Modern CSS and semantic markup techniques in use across the
net today virtually ensure that ie4 users will have a very
badly broken experience anyway.
But is that also true of NetFront 4 or IceBrowser 4?
We cannot save them, and it is often costly to try.
It is not more costly to provide clean degradation as a general fall-back
path than doing so only for script disabled IE 6.
The best approach for these browsers, if a developer
decides that it's worth taking one at all,
What made it the developer's decision? The developer is unlikely to be
developing a web based system for their own exclusive use, and whatever
purpose the system being developed has, and the (possibly business)
criteria of the end-client are much more relevant to overall design
decisions than the limitations of the developer.
is to simply hide script and styles (and other "enhancement"
layers) from these browsers altogether.
That implies an ability to identify web browsers, before you even get to
the question of how you would "hide" things from them.
Regarding degradation in the case of sending a function to
setTimeout: Unless I'm mistaken, the default toString() method
of a function has always been something like:
"function <name>() {
...
}"
More a massive over simplification than a mistake. Historically it has
not been possible to assume that the output of a function's toString
method would result in code that could be substituted for the original
function defining code and in that context result in the same function
object. The impression that this may be the case is only held by people
who haven't looked very extensively, or very hard.
Passed into setTimeout or setInterval, this will fail
silently,
Mostly yes, as I said above, but silent failure is not a rout to good
planed clean degradation in more than a very few cases. And with an
anonymous function the failure may not be silent.
creating a function object and (if its unnamed) immediately
garbage- collecting it.
That would depend on the way in which the string is interpreted. If it is
to be interpreted as a Program (as - eval - would) then the string
representation of an anonymous function (in the form "function( ... ){
.... }") would be a syntax as no Statement is allowed to commence with
"function" and the Identifier is not optional in a FunctionDeclaration.
I'm not sure that's such a bad fallback.
If that is what happens. A reported syntax error may be more disruptive.
IE4 users get no switching image goodness, but they also don't
get annoying error messages.
Why the fixation with IE 4? However, you were proposing using function
references with all uses of setTimeout, so loosing a bit of harmless
image swapping is not the extent of the consequences of failure here.
It may be possible to change the Function.prototype.toString() to
support old browsers.
with({ts:null}){
ts=Function.prototype.toString;
Function.prototype.toString = function () {
return '('+ts.call(this)+')()';
This relies on the function - toString - method returning a string that
can be turned into a functionally equivalent function object (which has
been observed not to be universally the case), that the function's have -
call - methods (which was introduced in ECMA 262, 3rd Ed. and so not too
good an idea in a back-compatibility fall-back path), and the function
used with setTimeout looses its identify (and so its scope chain) in the
process.
Custom - toString - methods are the means of providing fall-back for
setTimeout, but better alternatives, specifically assigned to the
functions used with setTimeout, have been proposed for the task.
}
}
However, I'm not sure if that would actually work in IE4,
IE 4 did not support the - call - method of functions. But why the
obsession with IE 4?
since I usually just disregard browsers that old and so
have no experience with them.
The more recent browsers that do not provide support for function
references as the first argument to setTimeout are probably more
significant.
Richard.
