modisposition

I was doing a couple of tests in my bloody Android and I don't even know how I ended up with such snippet ... anyway, accordingly with @ ppk table sourceIndex is a node property compatible with every version of Internet Explorer and latest Opera browser but not with Chrome, Firefox, or Safari (WebKit Android and iPhone as well). Being these unsupported browsers compatible with both native Array.prototype.indexOf and __defineGetter__ and being 5 to 100 times faster than IE, I thought: why don't put this as well into vice-versa ? /** sourceIndex by vice-versa - Mit Style License * @target FireFox, Safari, Chrome */ if(typeof document.documentElement.sourceIndex == "undefined") HTMLElement.prototype.__defineGetter__("sourceIndex", (function(indexOf){ return function sourceIndex(){ return indexOf.call(this.ownerDocument.getElementsByTagName("*"), this); }; })(Array.prototype.indexOf)); ; I so much would have cac...

During last evenings I have updated a little bit my vice-versa project . Since vice-versa aim is to bring in every browser what is possible to implement and, in most of the cases, already defined as standard (from W3 or MSDN when it is worthy) I decided to get rid of the Ariel Flesler fast trim proposal to introduce my lightweight full specs String.prototype.trim, trimLeft, and trimRight. For full specs I mean that vice-versa String.prototype.trim replace exactly same characters replaced by native Firefox 3.5 implementation, rather than only characters which code is less than 33 as is for Ariel proposal. The good part of vice-versa ( to be honest I cannot find bad parts so far ;) ) is that every single file is stand-alone, so if you do not like benefits the entire " lib " could bring, you can always adopt only one of its files, for example the String one, the Array one, or the last full specs ECMAScript 5 Date constructor , compatible with ISO strings, new Date("2009-0...

Just a quick update about vice-versa , I have implemented fireEvent to fire, as the method name says itself, events after attachEvent. Do you prefer the dispatchEvent way with at least 3 different ways to initialize an event usually fired only to call the callback? It is this: a.addEventListener("click", function(evt){ location.href = evt.target.href; evt.preventDefault(); return false; }, false); // powerful uh? now think // when you used something different // from defaults ... var evt = document.createEvent("MouseEvents"); evt.initMouseEvent( "click", true, true, this, 0, 0, 0, 0, 0, false, false, false, false, 0, null ); a.dispatchEvent(evt); against what I think is often all we need: a.attachEvent("onclick", function(){ location.href = event.srcElement.href; return event.returnValue = false; }); a.fireEvent("onclick"); and that's it :)

Array.forEach(document.all, function(node, i, all){ // vice-versa project }); well, there are few things I can say here, and first one is: please, if interested, help me! The second one is my vision, a web where rather than criticisms, there is more collaboration to obtain good overall performances improving code quality. This is not my old JSL project, this is a new groove, a new project, a non library , something I hope you will all appreciate. But, if not, I am here to discuss about it :) vice-versa project Have fun with Web Development! Update Implemented a TaskSpeed test file for vice-versa project. Here first results ordered by average. browser Pure vice Moo qoox dojo YUI AVG Dom versa Tools doo -------------------------------------------------------------------- Safari 4 198 114 392 205 246 410 260.83 Chrome 1 251 273 589 279 336 692 403.33 Opera 10 215 206 764...