Quick reply on the stats: while on a downward trend, IE6 + 7 + 8 is > 33%. A cool third of all browsers. Given their generally conservative attitude towards upgrading software, my educated guess would be that this percentage is (much) higher in the enterprise.
I have no idea how to add 'goog.events' as a polyfil, as it is compiled into the code on publishing, long before we know which browser we're addressing. EdB On Friday, April 26, 2013, Alex Harui wrote: > > > > On 4/26/13 2:24 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > > > Ok, since you apparently don't trust my expertise on this, and I care > > too much about this project to just let you figure this out when > > things start breaking, an analysis of the current solution and why I > > think 'goog.events' is superior: > Hi Erik, > > Thanks for the detail analysis. That was very helpful and the kind of > thing > I was looking for. It is not an issue of trust, it is about having > objective criteria recorded somewhere so we can look back later and know > why > we made a decision. > > I should have provided my line of thinking earlier. It is this: > > The top browser market share looks like this based on [1]. > Microsoft Internet Explorer 8.0 23.23% > Microsoft Internet Explorer 9.0 20.62% > Firefox 19 13.55% > Chrome 25.0 13.42% > (everything else is below 10%) > > I think we can all agree that IE8 is on a downward trend. Of the remaining > (IE9, FF, Chrome), it appears that they have all standardized on DOMEvents. > Is this not true? Because if they have, then the code minimalist in me > would want to just use the built-in browser code and handle IE8 as a > polyfill. If they haven't standardized, then you can stop reading and > check > in your changes. > > > > > The current solution is actually 3 solutions: the one in > > 'HTMLElementWrapper', the one in 'EventDispatcher' and finally > > 'IE8Utils'. The first wraps DOM events, the second is a custom > > solution to manage non-DOM events, number 3 combines both approaches. > > What if someone want to write a component that extends > > HTMLElementWrapper but wants to use a non-DOM event? Wait, that is > > what already happens in 'Application'. There you have to override > > 'addEventListener' (without the JSDoc indicating you did), basically > > creating a fourth implementation. > > > > 'removeEventListener' is only implemented on instances of > > 'HTMLElementWrapper' meaning there is no way to remove event listeners > > added through the other 3 implementations. > > > > 'createEvent' uses 'document.createEvent' and 'document.initEvent', > > both which are deprecated by Mozilla [1], not exactly improving the > > future-proofness of the current solution. All events are created with > > both 'canBubble' and 'cancelable' set to false, without the ability to > > change this. The IE8 implementation - using > > 'document.createEventObject' - is not separated out like other IE8 > > specific implementations. > > > Good point about other objects dispatching events that don't wrap DOM > objects and that the IE8 impl is not fully separated out, but I think you > are misinterpreting the other code you found, especially what is going on > in > Application. My bad for not putting comments on that. Regarding > createEvent, isn't it true that for the non-IE8 browsers listed above you > can just call "new Event()" and use custom event "types" (like "initialize" > or "idChanged") or is that still not standardized? If that's not > standardized, then again, you can stop reading and check in. > > > The 'IE8Utils.EventMap' is by no means complete. It also uses the 'on' > > prefix that is never added to the event type specification anywhere in > > the framework. This means all IE8 events fail the 'EventMap' test and > > are handled as custom events... > Yup, that's why I am now in favor of using goog.events for IE8. > > > > I could go on (trust me?), but I think the above is enough to make my > > case and I don't feel like spending a lot of time on this anymore. > > > > TL;DR: there are currently 4 (!) possibly conflicting and certainly > > confusing partial implementations of an event handling system. I > > suggest we replace this with one thoroughly tested and real world > > proofed solution, which I already implemented and is ready to go. > So there isn't 4, but there is 3. I could be wrong, but I didn't think the > dividing line was whether you were sending a DOM event or not, but whether > you were wrapping a built-in object that could dispatch events. Then the > three are: > 1) wrapped built-ins (Label, Button, and even HTTPService) > 2) other stuff (Timer appears to be the only example right now) > 3) IE8 > > The code-minimalist, pay-as-you-go philosophy says that folks who don't > care > about IE8 and build an app entirely out of pieces in #1 (which is totally > possible and probable, especially for apps intended for mobile) shouldn't > need to carry goog.events around. > > I think goog.events is a bit heavy for #2 since it doesn't need > bubble/capture, but I'm now ok with using it there for now. Maybe we'll > find a smaller implementation someday, maybe not. > > And I'm now all for using goog.events for #3. > > But again, this all presumes the browsers other than IE8 have standardized > on their event API which means: > A) use of "new Event() instead of createEvent/initEvent > B) I can pass any string I want into "new Event()" > > Thoughts? And thanks again for taking the time. > > [1] > > http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd= > 0 > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
