ELF: Ha ha!
Thanks for sharing!

Changes: added Konqueror & 64bit IE support (I assume @_win32 doesn’t work on 64bit but have not been able to test (vista x64 blue screens upon boot on my hardware)), it’s also a bit smaller in file size.

Well, I have a Mac, but I don’t want to taint it with a nasty IE 5.
Besides, I don’t put any extra time into supporting IE on Mac anymore, since developing on it stopped a number of years ago and the user base is just too small.

No matter if we’re accessing it or not, I doubt that clipboardData or any external property are available in IE on Mac, so just checking if it’s there or not will likely fail.

And there is a whole list of “externals” in IE, like window.window. It doesn’t have to be the one above, we just have to settle for one that’s found in all versions of it. In other browsers that list is limited to the Java stuff (at least Opera and Mozilla family).

Admitted, looking the presence of window.clipboardData on the Mac is probably not the way to go, but hey, I just picked one as an example…

Interesting approach! Two things to mention, though:

First, for security reasons, it seems likely, (at least to me), that maybe IE will block the access to clipboardData.

Second, I haven’t tested, but I’m fairly sure IE on Mac wouldn’t let you access clipboardData.

I’ve kept the original code between the conditional comments intact, to keep it simple here. It’s also possible to add the script by the DOM, but there are a few gotcha’s there, and that wasn’t the goal I set out for anyway. For those interested, it IS solved by yours truly .

The alternative here requires a bit extra code, but those funcs (and other typecheckers) are missing in javascript anyway. It’s one of those things that are in my common.js. Also I’ve written it out quite elaborate, just to make the workings clearer. Everyone feel free to crunch it as much you like .

if (isExternal(window.clipboardData))
{
document.write( "<script id=__ie_onload defer src=javascript:void(0)><\/script>" );
var script = document.getElementById( "__ie_onload" );
script.onreadystatechange = function() {
if ( this.readyState == "complete" ) {
init(); // call the onload handler
}
};
}

function isFunction(item)
{
return typeof item === "function";
}

What we do here is searching for an object that is accessible to javascript, but isn’t part of it. Like the Packages (from Java) in Mozilla for example. What I found was that IE has quite a few of them, and I picked one that seemed suitable. Instead of wrapping the IE code in those UGLY statements, this way seems much nicer and less ‘hack’ to me.

What I like to have now is some feedback from IE users on the Mac. Can I use this test there too? Logically it would work just fine, but one never knows with Explorer .

I’ve seen some variants on this, but this one seems to be the easiest to use. Gonna try to rewrite it if you don’t mind, so the ugly conditional statements can go (really, really hate ‘em, but that’s just me).

I’ll be in touch if I succeed and it’s err… presentable .

The script in this post doesn’t use document.write at all.

I did create my own functions to handle events to use multiple functions (see below). I am not sure this is the most elegant way to do this, but it works fine.

// global variables
var onload_events=”;
var onmousemove_events=”;
var onmouseup_events=”;

function onload_push(str) {
if(str.substr(str.length-1,1)!=’;') str+=’;';
onload_events+=str;
window.onload=function() {
eval(onload_events);
}
}

function onmousemove_push(str) {
if(str.substr(str.length-1,1)!=’;') str+=’;';
onmousemove_events+=str;
document.onmousemove=function(evt) {
eval(onmousemove_events);
}
}

function onmouseup_push(str) {
if(str.substr(str.length-1,1)!=’;') str+=’;';
onmouseup_events+=str;
document.onmouseup=function(evt) {
eval(onmouseup_events);
}
}

function onload_init() {
// flag to look after if the document was loaded
document.loaded=true;
}

// examples
onload_push(‘onload_init()’);
onload_push(’some_function()’);
onmousemove_push(’some_other_function()’);
onmousemove_push(someojb+’.property=”value”‘);
onmousemove_push(someobj+’.method(evt)’);

Regarding the conditional comments, I’m not a 100% sure. For that I used what was created and tested in Dean’s script. So, you may very well be right, but since Dean’s script has been thoroughly tested by lots of talented people and verified to work, I’m a bit wary about changing that part.

The window.onload part does indeed trigger the ELO method twice in web browsers that successfully applied the event in any of the ways above in the code. Therefore, the ELO object has a loaded property which in turn prevents multiple execution of already called functions.

If my coding is working correctly (my limited testing suggests so), the number of if’s asked is kept at a minimum, including having the normal “if … else if …” inside a conditional comment (so it’s completly ignored by IE).

The last “window.onload” could be kept outside the “if … else if” to trigger in all browsers, though wouldn’t this fire the “ELO event” twice?

Sorry if I’m not making any sense at all; JavaScript really isn’t my native language, especially when we’re throwing in bits of this strange and sheldom spoken dialect from MS….

Good question.

The first part of the script is a way to accomplish conditional comments in a script file that will only work in IE. And since one wants the window.onload at the bottom for all web browsers as an extra insurance, that leaves only the if clauses for Mozilla/Opera 9 and Safari,

So yes, if you want to you can use if...else for the Mozilla/Opera 9 and WebKit part, that is an option.

Wouldn’t it be better to integrate the different parts of the “@if … if … else if … else …” tighter together? Thus avoiding running browser specific/unnecessary parts of the code when the script allready have identified a browser…

Possibly something like;

/*@cc_on
/*@if (@_win32)
    // IE on Win32
@else @ */
    if (document.addEventListener) {
        // Mozilla/Opera
        }
    else if (navigator.userAgent.search(/WebKit/i) != -1) {
        // WebKit (Safari)
    else {
        // Other browsers
        }
/*@end @ */


I wouldn’t necessarily say that the push implementation is wrong, but instead sufficient for its use here. If you want to make it more flexible and accept several parameters, you just have to loop through the arguments, just like in your example.

I’m not sure I’d agree that the scope for the parameters would be just for the eval call; it depends on what parameters/possible object properties you refer to.

And yes, you can fairly easily expand the functionality to accept functions as well as strings, and my initial version used only function references. In the end, though, I decided to take this route in this version presented here, because it was sufficient for my needs.

If you want to enhance it with more support/flexibility for the cases you would use it in, by all means, add the functionality you seem fit.

That ‘push’ implementation is wrong. Here’s one that follows the spec (push multiple things onto the array at once, and return the new length of the array):

if (typeof Array.prototype.push != "function") {
  Array.prototype.push = function() {
    for (var i = 0; i < arguments.length; i++) {
      this[this.length] = arguments[i];
    }
    return this.length;
  }
}


Also, if you used functions instead of strings on the call-stack, you’d be able to use closures for parameterisation, instead of limiting yourself to parameters in the scope of the eval call. Of course, it wouldn’t take much effort to accept both strings and function references.