Event firing order issue in IE6 / IE7 version

[jslegers]

I tried doing the following :

• First, I select 4 button elements and attach a 'click" event to those buttons.
• Then, I'm selecting a single span element and attach a "mouseover" event to that span.
• Finally, 'm selecting that same span along with a link (a) element and attach a "mouseover" event to them.

With the IE8 version, my code breaks completely ( see #8 )

With the IE6/IE7 version, event handling works fine for each of the selections and behaves the same across IE6-IE8. The only isue I'm having, is the classic random event firing order problem : when I hover above my span, it fires the second event first.

[JamesMGreene]

IIRC, the only way to get around this is to run your own event system to abstract it away, e.g. the underlying code attaches one handler per event type per element (when a user-defined handler is first added for that event-element pair), and then that handler is responsible for managing and dispatching all of the user-defined handlers.

Basic implementation concept from jQuery core:
https://github.com/jquery/jquery/blob/ef154cc530155bc1d39840761313649eddcaae3a/src/event.js#L102-117

[jonathantneal]

I'm stoked to see the recent attention to this script. I continued my work on this script @ https://github.com/jonathantneal/polyfill/blob/master/source/Window.prototype.Event.ie8.js

I will backport it to this project.

[JamesMGreene]

Can't speak for @jslegers but I'm more than happy to just watch the new repo instead. I'd hate to miss fixes and such if you're not actively backporting to here.

[jonathantneal]

@JamesMGreene, I'd also love to know what you think of the polyfill project.

[jslegers]

@JamesMGreene & @jonathantneal :

I think polyfills are a much better solution for dealing with browser differences than abstraction layers as it offers much better performance for modern browsers for any custom JS implementation that needs to be cross-browser. I definitely support projects like the polyfill project for trying to provide a complete solution to take care of this.

What I don't like about the polyfill project in its current form, is that it gives you a monolithic file containing all the polyfills it thinks you need baded on browser sniffing. One reason is browser sniffing being unreliable and not very future proof. Another reason is my preference for asynchronously loaded modules in favor of monolithic files.

I would prefer feature sniffing a la Modernizr and a modular file system with one implemented feature per file. You'd then just run a configurable range of tests and asynchronously load the corresponding polyfill only when a test fails, using using a module loader like RequireJS ( http://requirejs.org/ ), YepNope ( http://yepnopejs.com/ ) or LABjs ( http://labjs.com/ ).

To avoid an unnecessary amount of tests for modern browsers, you could run tests in hierarchies, with tests for older features only being executed if tests for newer features fail. Or you could just have users run a test whenever they need a certain feature rather than in advance, to avoid any polyfills being loaded that you never are going to use anyway.

Anyway, at the moment I care most about adding support for standard implementations of QuerySelector / QuerySelectorAll , AddEventListener, XMLHttpRequest, JSON.parse and DOMParser to IE6-IE8. How many of these are fully implemented in the polyfill project and where can I find them? I'm a bit confused about how the source code is structured.

[JamesMGreene]

I have some of the same concerns as @jslegers:

1. Not a fan of the UA sniffing but it is an interesting technique for the purpose of minimalistic polyfilling via a single script tag.
2. I am also very confused about the structure of the polyfill project, especially regarding which files are used for which versions of IE (and friends).

[jslegers]

@JamesMGreene & @jonathantneal :

Dynamic asynchronous loading also allows you to use a single script tag.

Here's how I organised my JS code in Cascade Framework ( http://cascade-framework.com/ ) :

• I included a single JS file in the document header that contains the htmlshiv along with an Ecmascript 5 polyfill ( https://github.com/inexorabletash/polyfill ), using conditional comments to ensure it's only loaded for IE<9
• I included a single JS file at the bottom of the document body that takes care of everything else.

The file at the bottom does the following :

• first, it dynamicly loads YepNope (renamed "Loader" because it seemed a more suitable name)
• then, it uses YepNope to load some other files

The files loaded with YepNope are the following sequence :

• a console shiv (to allow easier debugging in old IE), loaded only when console can't be found
• a slighlty customized version of Modernizr (renamed "Detector") for easier feature detection
• a file that contains the site-specific code
• the Google Analytics file

You can find the actual code at https://github.com/jslegers/cascadeframework/blob/master/assets/js/app.js

The site-specific code loads dependencies in a similar way :

• it first loads prettify
• it loads jQuery 1.9 or 2.0, depending on browser sniffing (haven't come up with a better solution yet)
• it loads the jQuery Easing library
• It loads the Cascade Framework JS code that includes JS helpers and behaviors
• it loads page specific JS code

You can find the actual code at https://github.com/jslegers/cascadeframework/blob/master/assets/js/site.js

Note that this is very alpha-stage code that can most definitely be improved in a multitude of ways, but it does work as expected in IE6+, Opera, Firefox, Chrome and Safari. I think a similar structure might be interesting for a project like the polyfill project.

[jonathantneal]

The polyfill project is:

• A collection of independent, succinct polyfills, named for the precise object and method they are patching, e.g. Element.prototype.classList, Date.prototype.toISOString, Array.prototype.forEach, and Object.defineProperty.

All of these polyfills rely on existing, platform-agnostic JavaScript. For instance, Window.prototype.Event polyfills window.Event by relying on document.createEvent. As opposed to...

• A collection of polyfills, named for the precise object, method, and vendor/version they are patching, e.g. Window.prototype.localStorage.ie7, Window.prototype.getComputedStyle.ie8, and Element.prototype.matches.o ( notice the trailing vendor/version at the end ).

All of these polyfills rely on legacy, platform-specific technologies. For instance, Window.prototype.localStorage.ie7 relies on IE≤7's element.addBehavior('#default#userdata'), Window.prototype.getComputedStyle.ie8 relies on IE≤8's element.currentStyle, and Element.prototype.matches.o relies on Opera≤12's Element.prototype.oMatchesSelector method.

To avoid the pitfalls of UA sniffing ( future-proofing technologies not yet implemented in the latest releases of the browser ), scripts like Element.prototype.matches.webkit check for Element.prototype.matches before patching it with the vendor-specific Element.prototype.webkitMatchesSelector.

I agree that UA sniffing is a dangerous game that turns off developers who recall its historical abuse as a means of future-proofing. I believe that sniffing for IE6, IE7, and IE8 is very reliable and very future proof, considering that Microsoft will not be releasing a new IE6, IE7, or IE8 browser.

I think of it this way; my project does not sniff for the future. it sniffs for the past.

Please let me know if you are still confused about the structure of the polyfill project, or if you are still concerned about the polyfill project and future proofing. I hope I've explained the project clearly, and I'm totally open to exploring these concerns further.

[JamesMGreene]

@jonathantneal Thanks for the background.

@jslegers You might be interested in mout.

[jonathantneal]

If any of you would like to help modularize polyfill for those who prefer feature tests, let me know.