addEvent - The late entry :)

**Aaron Gray** · Jul 16 '08, 04:35 PM

Re: addEvent - The late entry :)

Drip IE memory leak detector :-

Sorry that should be :-

http://www.outofhanwell.com/ieleak/index.php?title=Main_Page

Aaron

**Aaron Gray** · Jul 20 '08, 12:15 AM

Re: addEvent - The late entry :)

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6e6hnqF5b2 k3U1@mid.indivi dual.net...

>I jokingly say this is the late entry :)
>
Okay I have read all the event entry comments from John's Resig's AddEvent
comepition blog :-
>
http://ejohn.org/projects/flexible-javascript-events/
>
and put together the following offering for my LGPL'ed library functions
:-
>
function addEvent( el, type, fn, cascade) {
if ( el.addEventList ener) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)
}
else if ( el.attachEvent) {
el[type+fn] = function() {
fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
else
el[ 'on'+type] = fn
}
function removeEvent( el, type, fn, cascade) {
if ( el.removeEventL istener) {
cascade = cascade || false;
el.removeEventL istener( type, fn, cascade)
}
else if ( el.detachEvent) {
el.detachEvent( 'on'+type, el[type+fn])
el[type+fn] = null; // clear hash and IE memory leak
}
else
el[ 'on'+type] = null
}
>
>
Lessons :-
>
call W3C first to satisfy Opera and for common sence, then MS as this is
usually easy detectable, then legacy.
Based on 'Weisi Su' entry on
http://ejohn.org/projects/flexible-j...comment-276560 and
Michael White' suggestion using W3C first for correct operation on Opera.
plus legacy event handling added by me. Which in the end was all very
simular to some code I wrote the previous day and forgot about :)
>
Added cascade parameter that defaults to bubble on W3C calls.
>
The full test case can be found here :-
>

http://www.aarongray.org/Test/JavaScript/EventTest.html

>
Okay I have tried it on IE6 with and Drip and it does not seem to produce
and memory leaks AFAICS.
>
Drip IE memory leak detector :-
>
http://ejohn.org/projects/flexible-javascript-events/
>
I have tested it on 32Bit Vista IE7.0.6001, Safari 3.1.2, and Opera 9.51;
XP IE6.
>
Any browser testing appreciated, particularly on older and less well known
ones.
>
Well thats about it folks...any comments...hole s...or suggesttions are
most welcome.

Here's some slightly more efficient code :-

if ( window.addEvent Listener) {
var addEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)
}
var removeEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.removeEventL istener( type, fn, cascade)
}
}
else if ( window.attachEv ent) {
var addEvent = function( el, type, fn) {
el[type+fn] = function(){
fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
var removeEvent = function( el, type, fn) {
el.detachEvent( 'on'+type, el[type+fn])
el[type+fn] = null; // clear hash and IE memory leak
}
}
else
{
var addEvent = function( el, type, fn, cascade) {
el[ 'on'+type] = fn
}
var removeEvent = function( el, type, fn) {
el[ 'on'+type] = null
}
}

Test case :-

http://www.aarongray.org/Test/JavaScript/EventTest2.html

Aaron

**Aaron Gray** · Jul 20 '08, 12:35 AM

Re: addEvent - The late entry :)

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6efe1iF6oo 4aU1@mid.indivi dual.net...

legacy case :-

{
var addEvent = function( el, type, fn, cascade) {

cascade parameter should not be here

el[ 'on'+type] = fn
}
var removeEvent = function( el, type, fn) {
el[ 'on'+type] = null
}
}

if ( window.addEvent Listener) {
var addEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)
}
var removeEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.removeEventL istener( type, fn, cascade)
}
}
else if ( window.attachEv ent) {
var addEvent = function( el, type, fn) {
el[type+fn] = function(){
fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
var removeEvent = function( el, type, fn) {
el.detachEvent( 'on'+type, el[type+fn])
el[type+fn] = null; // clear hash and IE memory leak
}
}
else
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = fn
}
var removeEvent = function( el, type, fn) {
el[ 'on'+type] = null
}
}

Correct test case :-

http://www.aarongray.org/Test/JavaScript/EventTest2.html

Aaron

**Aaron Gray** · Jul 20 '08, 01:55 AM

Re: addEvent - The late entry :)

Here's yet another mod :-

if ( window.addEvent Listener) {
var addEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)
}
var removeEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.removeEventL istener( type, fn, cascade)
}
}
else if ( window.attachEv ent) {
var addEvent = function( el, type, fn) {
el[type+fn] = function(){
fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
var removeEvent = function( el, type, fn) {
el.detachEvent( 'on'+type, el[type+fn])
el[type+fn] = null; // clear hash and IE memory leak
}
}
else
{

if ( isIE)
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = function(){
fn.call( el, window.event);
}
}
}
else
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = fn
}
}

var removeEvent = function( el, type, fn) {
el[ 'on'+type] = null
}
}

Needs 'isIE' variable setting.

Aaron

**Aaron Gray** · Jul 20 '08, 01:55 AM

Re: addEvent - The late entry :)

"Aaron Gray" <ang.usenet@gma il.comwrote in message
news:6efjt8F6gp 0sU1@mid.indivi dual.net...

Here's yet another mod :-
>
if ( window.addEvent Listener) {
var addEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)
}
var removeEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.removeEventL istener( type, fn, cascade)
}
}
else if ( window.attachEv ent) {
var addEvent = function( el, type, fn) {
el[type+fn] = function(){
fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
var removeEvent = function( el, type, fn) {
el.detachEvent( 'on'+type, el[type+fn])
el[type+fn] = null; // clear hash and IE memory leak
}
}
else
{
>
if ( isIE)
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = function(){
fn.call( el, window.event);
}
}
}
else
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = fn
}
}
>
var removeEvent = function( el, type, fn) {
el[ 'on'+type] = null
}
}
>
Needs 'isIE' variable setting.

Here's a test case :-

http://www.aarongray.org/Test/JavaScript/EventTest3.html

Aaron

**dhtml** · Jul 20 '08, 02:05 AM

Re: addEvent - The late entry :)

On Jul 19, 6:49 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

Here's yet another mod :-
>

There are some significant differences in attachEvent and
addEventListene r.

* w3c DOM Event bugs in Webkit and Safari (and probably a lot in Opera
that I'm not aware of).
* w3c DOM Events bubble as specified, IE events bubble differently,
like legacy events (by "legacy" events, I mean el.onclick = ...)
* different thisArg - attachEvent's this is always window

Needs 'isIE' variable setting.

Better stick to feature and capability detection.

Garrett

>
Aaron

**dhtml** · Jul 20 '08, 02:05 AM

Re: addEvent - The late entry :)

On Jul 19, 6:49 pm, "Aaron Gray" <ang.use...@gma il.comwrote:

Here's yet another mod :-
>

There are some significant differences in attachEvent and
addEventListene r.

* w3c DOM Event bugs in Webkit and Safari (and probably a lot in Opera
that I'm not aware of).
* w3c DOM Events bubble as specified, IE events bubble differently,
like legacy events (by "legacy" events, I mean el.onclick = ...)
* different thisArg - attachEvent's this is always window

Needs 'isIE' variable setting.

Better stick to feature and capability detection.

Garrett

>
Aaron

**Richard Cornford** · Jul 20 '08, 01:05 PM

Re: addEvent - The late entry :)

Aaron Gray wrote:

Here's yet another mod :-
>
if ( window.addEvent Listener) {

The W3C - EventTarget - interface is specified as being implemented by
objects implementing the core DOM Node interface (and in reality are
only reliable on objects implementing Element). The window object is not
a Node and so it is not valid to infer that if a window object has an -
EventTarget - method then all Nodes/Elements will, or vice versa. Opera
7, for example, had an - attachEvent - method on its window objects but
no - addEventListene r -, while all of its nodes had - addEventListene r -
methods. Thus you are forcing Opera 7 to use the (less efficient)
attachEvent branch having previously asserted that Opera browsers did
not work particularly well with that branch.

var addEvent = function( el, type, fn, cascade) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)

<snip>

else
{
>
if ( isIE)
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = function(){
fn.call( el, window.event);

Are you suggesting here that IE 4 (which is below your ECMAScript 3
minimum for script support) did not call functions assigned to its
intrinsic event properties with the - this - value - being a referee to
the element to which the listener was attached? Or is this an attempt to
normalise the event object for the - fn - functions, and if so why not
do so in the next branch as non-IE browsers that are not DOM standard
may have chosen to only emulate IE in their event handling?

}
}
}
else
{
var addEvent = function( el, type, fn) {
el[ 'on'+type] = fn
}
}

Richard.

**Aaron Gray** · Jul 20 '08, 05:25 PM

Re: addEvent - The late entry :)

"Richard Cornford" <Richard@litote s.demon.co.ukwr ote in message
news:g5vcod$65e $1$8300dec7@new s.demon.co.uk.. .

Aaron Gray wrote:

>Here's yet another mod :-
>>
>if ( window.addEvent Listener) {

>
The W3C - EventTarget - interface is specified as being implemented by
objects implementing the core DOM Node interface (and in reality are only
reliable on objects implementing Element). The window object is not a Node
and so it is not valid to infer that if a window object has an -
EventTarget - method then all Nodes/Elements will, or vice versa. Opera 7,
for example, had an - attachEvent - method on its window objects but no -
addEventListene r -, while all of its nodes had - addEventListene r -
methods. Thus you are forcing Opera 7 to use the (less efficient)
attachEvent branch having previously asserted that Opera browsers did not
work particularly well with that branch.

Okay I have made a mod here then :-

if ( typeof addEventListene r != "undefined" )
...

This appears to function correctly on IE, FF, Safari, and Opera.

Thanks,

Aaron

**Aaron Gray** · Jul 20 '08, 05:25 PM

Re: addEvent - The late entry :)

"Richard Cornford" <Richard@litote s.demon.co.ukwr ote in message
news:g5vcod$65e $1$8300dec7@new s.demon.co.uk.. .

Aaron Gray wrote:

>Here's yet another mod :-
> var addEvent = function( el, type, fn, cascade) {
> cascade = cascade || false;
> el.addEventList ener( type, fn, cascade)

<snip>

>else
>{
>>
> if ( isIE)
> {
> var addEvent = function( el, type, fn) {
> el[ 'on'+type] = function(){
> fn.call( el, window.event);

>
Are you suggesting here that IE 4 (which is below your ECMAScript 3
minimum for script support) did not call functions assigned to its
intrinsic event properties with the - this - value - being a referee to
the element to which the listener was attached? Or is this an attempt to
normalise the event object for the - fn - functions, and if so why not do
so in the next branch as non-IE browsers that are not DOM standard may
have chosen to only emulate IE in their event handling?

So I can just drop that behaviour, and revert back to the previous version
for legacy support.

Aaron

**Peter Michaux** · Jul 20 '08, 05:45 PM

Re: addEvent - The late entry :)

On Jul 16, 8:17 am, "Aaron Gray" <ang.use...@gma il.comwrote:

I jokingly say this is the late entry :)
>
Okay I have read all the event entry comments from John's Resig's AddEvent
comepition blog :-
>
http://ejohn.org/projects/flexible-javascript-events/

I'd recommend not taking anyone's word as gospel in the JavaScript
world. There are certain programmers like Richard Cornford, Martin
Honnen and Douglas Crockford with track records for being correct that
I default to thinking they are correct and seriously wonder why if I
seem to think they are wrong. Otherwise I consider just about everyone
else wrong by default.

and put together the following offering for my LGPL'ed library functions :-

Why LGPL? There are JavaScript libraries under the MIT and BSD
licenses which are more liberal than LGPL.

Offering your library under the LGPL means, most importantly, you are
offering your library to the world. I think it is great you are taking
the project of writing a library seriously but if you are going to
release your library publicly you may want to give it a very low
version number like 0.0 or 0.1 so people know you are just starting to
learn the issues of both JavaScript and cross browser coding.

function addEvent( el, type, fn, cascade) {
if ( el.addEventList ener) {
cascade = cascade || false;
el.addEventList ener( type, fn, cascade)
}
else if ( el.attachEvent) {
el[type+fn] = function() {
fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
else
el[ 'on'+type] = fn}

Richard Cornford has pointed out some major problems in the code
above, the asymmetrical use of "cascade", the implicit toString of fn,
the non-equivalent fallback use of element properties like "onclick",
the creation of circular memory leaks in IE6 with no way to clean up.

What about the preventDefault problem in Safari versions something
like 2.0.2 and less? If an event listener for click or double click
events is added to addEventListene r then preventDefault doesn't work?

What if the browser does support JavaScript but doesn't support any of
these types of event attachment APIs?

What if Internet Explorer 9 changes attachEvent to be an ActiveX
object so that the type converting test for el.attachEvent throws an
error even though a call to el.attachEvent( ) will work?

Why test which event model is the appropriate one for the browser each
time your addEvent is called when testing just the first time is
sufficient?

There are seemingly zillions of very fine details related to both
JavaScript and the browser environment that make writing your addEvent
function alone worthy of a very long investigation before declaring it
production ready for use on the general web and better than the
alternative libraries available for download today.

function removeEvent( el, type, fn, cascade) {
if ( el.removeEventL istener) {
cascade = cascade || false;
el.removeEventL istener( type, fn, cascade)
}
else if ( el.detachEvent) {
el.detachEvent( 'on'+type, el[type+fn])
el[type+fn] = null; // clear hash and IE memory leak
}
else
el[ 'on'+type] = null
>
}
>
Lessons :-
>
call W3C first to satisfy Opera and for common sence, then MS as this is
usually easy detectable, then legacy.

I think it would be a good idea to detect support for legacy before
using it. Better yet, follow Richard's advice that if legacy is good
enough it is always good enough or don't include legacy at all.

Based on 'Weisi Su' entry onhttp://ejohn.org/projects/flexible-javascript-events/#comment-276560and
Michael White' suggestion using W3C first for correct operation on Opera.
plus legacy event handling added by me. Which in the end was all very
simular to some code I wrote the previous day and forgot about :)
>
Added cascade parameter that defaults to bubble on W3C calls.
>
The full test case can be found here :-
>

http://www.aarongray.org/Test/JavaScript/EventTest.html

>
Okay I have tried it on IE6 with and Drip and it does not seem to produce
and memory leaks AFAICS.
>
Drip IE memory leak detector :-
>
http://ejohn.org/projects/flexible-javascript-events/
>
I have tested it on 32Bit Vista IE7.0.6001, Safari 3.1.2, and Opera 9.51; XP
IE6.

That is an extremely small set of OS/Browser combinations. I tested my
first try at a general purpose library on many

Page not found – Fork JavaScript

http://forkjavascript.org/welcome/browser_support

I plan on testing on quite a few more for v0.2 which I am writing now.

Any browser testing appreciated, particularly on older and less well known
ones.

Based on my experience, you will need to do all the testing yourself
which means having many operating systems available (e.g. Windows XP,
Mac OS X, Linux) and downloading many versions of old browsers. There
are many old versions of IE, O, S, NN, FF available on the web.

Well thats about it folks...any comments...hole s...or suggesttions are most
welcome.

Specify the exact requirements for your event code. Post them to the
group for criticism.

Slow down. Read the YUI event library, as an example, until you think
you have found all the things that are wrong with it. Code a better
version. Read another event library and repeat the cycle. It is a long
road ahead.

Peter

**Richard Cornford** · Jul 20 '08, 05:55 PM

Re: addEvent - The late entry :)

Aaron Gray wrote:

Richard Cornford wrote:

>Aaron Gray wrote:

>>Here's yet another mod :-
>>>
>>if ( window.addEvent Listener) {

>>
>The W3C - EventTarget - interface is specified as being implemented
>by objects implementing the core DOM Node interface (and in reality
>are only reliable on objects implementing Element). The window
>object is not a Node and so it is not valid to infer that if a
>window object has an - EventTarget - method then all Nodes/Elements
>will, or vice versa. Opera 7, for example, had an - attachEvent -
>method on its window objects but no - addEventListene r -, while
>all of its nodes had - addEventListene r - methods. Thus you are
>forcing Opera 7 to use the (less efficient) attachEvent branch
>having previously asserted that Opera browsers did not work
>particularly well with that branch.

>
Okay I have made a mod here then :-
>
if ( typeof addEventListene r != "undefined" )
...
>
This appears to function correctly on IE, FF, Safari, and Opera.

You have completely missed the point. The test was fine (well, the test
is actually debatable but I would have no problem with it), it is the
inference made from the test that is unfounded.

Richard.

**Richard Cornford** · Jul 20 '08, 05:55 PM

Re: addEvent - The late entry :)

Aaron Gray wrote:

Richard Cornford wrote:

>Aaron Gray wrote:

>>Here's yet another mod :-
>> var addEvent = function( el, type, fn, cascade) {
>> cascade = cascade || false;
>> el.addEventList ener( type, fn, cascade)

><snip>

>>else
>>{
>>>
>> if ( isIE)
>> {
>> var addEvent = function( el, type, fn) {
>> el[ 'on'+type] = function(){
>> fn.call( el, window.event);

>>
>Are you suggesting here that IE 4 (which is below your ECMAScript
>3 minimum for script support) did not call functions assigned to
>its intrinsic event properties with the - this - value - being a
>referee to the element to which the listener was attached? Or is
>this an attempt to normalise the event object for the - fn -
>functions, and if so why not do so in the next branch as non-IE
>browsers that are not DOM standard may have chosen to only
>emulate IE in their event handling?

>
So I can just drop that behaviour, and revert back to the previous
version for legacy support.

Again you miss the point. This is a question of providing a consistent
API. Either you normalise the event object and assert that the functions
passed in as listeners will receive a normalised event as their first
argument or you specify that the listeners are themselves responsible
for that aspect of event processing. It does not matter which you
choose, it is just that you should choose one or the other, document it
and implement it consistently.

Incidentally, if you are asked questions here you will get a lot
further, a lot faster, by answering them. Evasion is pointless.

Richard.

**Peter Michaux** · Jul 20 '08, 06:45 PM

Re: addEvent - The late entry :)

On Jul 20, 5:40 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

[snip]

(but any of those clunky 'bind' methods so beloved of library authors
would do just as well as an example).

Partial application is a common technique in lambda languages and not
looked down upon when used appropriately. The implementation in
JavaScript is not as aesthetic as in some other languages somewhat due
to the "this" issue in JavaScript; however, conceptually the binding
of some parameters to one functions and producing another function
taking no or less parameters is the same. I don't understand why you
would apparently balk at this concept. The use of a "bind" function is
not clunky, in my opinion.

[snip]

fn.call( el, window.event);
}
el.attachEvent( 'on'+type, el[type+fn])
}
else
el[ 'on'+type] = fn

>
If this branch is ever good enough it is also always good enough.

Functionally yes. I think, in this case, the third branch is
unnecessary even if implemented so all three branches have the same
behavior. If someone did think the third branch was necessary then the
first two branches (using addEventListene r or attachEvent) could be
justified as performance boosts. A large portion of the remainder of
your message below is related to keeping code small which is really
just for a performance boost.

There is, of course, the question of cancelling default actions and
propagation.

Do you happen to know of a way to detect the Safari versions which do
not honour calls to preventDefault for click or double click events
when the listener was attached using addEventListene r? There is a
"legacy" workaround using onclick and ondblclick properties of
elements but these are a bit ugly and have some drawbacks which need
documentation. At this point, since those versions of Safari have been
automatically upgraded, I'd rather put those versions of Safari down
the degradation path as though they didn't have event models at all. I
just don't know how to detect these versions of Safari.

[snip]

Recently I have been thinking about how to express what it is about the
attempt to be general that tends to results in code that bloated and
inefficient.

[snip interesting thoughts]

You an Matt Kruse have faced off many times about this whole "general"
library business. I don't quite see the fuss.

Matt is being a bit extreme by suggesting that the general position
reporting function should be written even though you have stated it
would be 2000+ statements and far too slow to be practical. Your
multiple implementations approach seems more appropriate in this
situation.

In messages like this one, you on the other hand seem to eschew things
"general" (though I don't think you do so 100%). Take, for example,
the scroll reporting code you wrote in the FAQ notes

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdScroll

I consider that level of "multi-browserness" sufficiently "general".
That is, I would be comfortable using this type of code on the
unrestricted web.

When you write that an "attempt to be general that tends to results in
code that bloated and inefficient" I think it is worth defining where
you draw the line between bloated and non-bloated code and efficient
and inefficient code.

If a "general" event library could be written in 10 lines would that
be acceptable to use in cases where it is more general than necessary?
What if it was 20 lines? 50 lines? 200 lines? 10000 lines? The
absolute size of the general code does matter to some extent.

Imagine the 200 line version's only drawback was download time and
initial interpretation, with no other runtime penalties. If that code
was already written, would it be worth using in situations where code
only 50% size could be used given the smaller code is not already
written. Writing 100 lines of event library code is probably not
trivial and require heavy testing. I would use the 200 line version as
it is ready, tested, cacheable, not really a download burden for the
majority of today's network connections (even most mobile networks).

I think that the extreme positions for and against "general" are both
faulty. When general code has acceptable performance, then creating
and maintaining one version is the winner. I think an event library
falls into this category. When the general code is unacceptably slow
then more optimized versions must be written. The position reporting
problem falls into this category.

"Premature optimization is the root of all evil" seems to apply and
suggests the strategy to use general code until there is push back
from some human (possibly the programmer, testers, customers) that the
code really is too slow. Then, and only then, fallback to the multiple
implementations strategy which is, in many regards, an optimization
strategy.

Peter

addEvent - The late entry :)

addEvent - The late entry :)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment