[announcement] ISKEET library 0.0.2

[Lasse Reichstein Nielsen]

Now, tell me how to get DOM 2 event listeners to work for Netscape/Mozilla
and Opera! ;-)

By following the specification?

With my method,

var listener = new Array();
listener.handleEvent = Code;
element.addEventListener( eventtype, listener, false );

it works on Netscape/Mozilla, whereas
Surpricing.

element.addEventListener( eventtype, Code, false );

doesn't.

Even more surpricing, as that is the correct way to do it.

Code is guaranteed to refer to a function of the form:

function Code( Event ) {

Then you are doing something wrong. It works for me.

---
var element = document.body;
var eventtype = "click";
var Code = function (Event) { alert(Event.target.tagName); };
element.addEventListener(eventtype,Code,false);
---
Works in both Mozilla and Opera 7.

Neither method works with Opera.

You must be doing something else wrong.

What I need is an algorithm that supports any of the HTML event types,
like "load", "mouseover" etc.

Qur? You need an *algorithm* that *supports* event types? What should
the algorithm DO?

I need them on window or at least document objects as well.

As it has beens tated, Opera only has addEventListener on DOM nodes,
and not on the window object. You have to treat the objects differently.

Or should I replace calls supplying window or document as element
with using the body-tag element?

Probably not. Just don't use the same method for all host objects.
It's not hard to test whether addEventListener exists.
/L

 

[Ekkehard Morgenstern]

By following the specification?

Well, the DOM specification says

"Object EventListener
This is an ECMAScript function reference. This method has no return value. The parameter is a Event object."

So I was doing everything right according to the /specification/.

However, by testing, I now found out, that Opera expects a /reference to a function object/, which is something different than a
regular reference to a function.

In your example, you used a function object as well:

var Code = function (Event) { alert(Event.target.tagName); };

I know changed the code in ISKEET_DocEncap_AddEventHandler to:

function ISKEET_DocEncap_AddEventHandler( EventType, Elem, Code ) {
var listener = function( Event ) { Code( Event ); }; /* using JavaScript closures */
if ( Elem.addEventListener ) {
Elem.addEventListener( EventType, listener, false );
}
else {
ISKEET_CEO_AddEventHandler( EventType, Elem, listener );
}
return listener;
}

And now it works with all browsers. Surprise, surprise.

I guess I will do some more code changes for v0.0.6 of ISKEET.

 

[Lasse Reichstein Nielsen]

Well, the DOM specification says

"Object EventListener
This is an ECMAScript function reference. This method has no return
value. The parameter is a Event object."

So I was doing everything right according to the /specification/.

However, by testing, I now found out, that Opera expects a
/reference to a function object/, which is something different than
a regular reference to a function.

What?
There is only one kind of reference in Javascript: The reference to an
object[1]. Functions are objects.
What else would a "reference to a function" be?

var listener = function( Event ) { Code( Event ); }; /* using JavaScript closures */

By extensionality, that would be equvialent to
var listener = Code;
Just msrginally slower and only accepting one argument.

if ( Elem.addEventListener ) {
Elem.addEventListener( EventType, listener, false );
}
else {
ISKEET_CEO_AddEventHandler( EventType, Elem, listener );
}
return listener;
}

And now it works with all browsers. Surprise, surprise.

Yes, that is pretty much what I write when I need to be cross-browser
compatible. First, test for addEventListener. Then test for attachEvent
(but wrap the function to make sure "this" points correctly). Otherwise,
use elem.on<event> directly (or with a wrapper so I can assign more
than one function and make sure the function is passed the event, even
in IE).

/L
[1] Except, blah, the language definition also uses "reference"
sligtly differently from both of us, to refer to the combination of an
object and a property (section 8.7: The Reference Type). It is not
what we are talking about.

 

[Brynn]

checkout
http://www.echoecho.com/

check the surfer stats on the right.

almost 99% are using IE ... and the other 1% are used to having
problems on the web .. don't feel too bad if your stuff only works 99%
of the time ... LOL

I am a server-side kinda guy anyway, and don't use JS for anything
more than cute little tricks.

Brynn

Opera 7, in any spoof mode, contains the word "Opera" in the user agent
string. If you had bothered testing that, you would know it. And your
statements seem to indicate that your knowledge base of Opera is very
limited with regards to its userAgent string and how to detect Opera in
general.


if (window.opera){
//opera code here.
}

<sarcasm>
Wait, I didn't check the userAgent string, I must have done it wrong.


Then "many sites" are poorly written by amateurs posing as professionals
that know what they are doing.


Again, if you are trying to "optimize" javascript, PHP is *not* the
place to try to do it. If you want javascript optimized, use javascript
to do it.

Brynn
www.coolpier.com

I participate in the group to help give examples of code.
I do not guarantee the effects of any code posted.
Test all code before use!

 

[Ekkehard Morgenstern]

almost 99% are using IE ... and the other 1% are used to having
problems on the web .. don't feel too bad if your stuff only works 99%
of the time ... LOL

I'll still try to make it work with as many browsers as possible, even
if they're just 1%. ;-)

Once I have a library that works with all or almost all browsers,
then I can just use that to code my web pages. And if there's a problem,
I can fix it in the library instead of the page code.

Someday, I'll also make a library for PHP that can do some further
automation, like generating framed and nonframed versions of a page
and text-only versions, and entry pages permitting the user to select
which version they want (possibly storing their preference in a cookie
so they're not asked again when revisiting the page with the same
browser).

I am a server-side kinda guy anyway, and don't use JS for anything
more than cute little tricks.

I used to do everything in PHP, with no JavaScript code at all,
but I'd like to make more modern-looking pages. ;-)

Like, I have code to make pages truly resizable, just like
application windows. When you resize the window, everything on the
page scales. In JavaScript! ;-)

I will integrate that stuff into the ISKEET library, it'll allow for
having "soft-frames", i.e. simulated frames, instead of real ones,
so you can put a background image behind it, for example.
(perhaps I'll also be able to create code for scalable background
images, simply by simulating them and putting everything on top
of them)

 

[Lasse Reichstein Nielsen]

checkout
http://www.echoecho.com/

check the surfer stats on the right.

almost 99% are using IE ...

The check <URL:http://www.thecounter.com/stats/2003/May/browser.php>
They only put IE at ~95%. And that is including 5.x, which can be both
5.0 (crappy) and 5.5 (better), two seriously different browsers.

Are you willing to ignore 5% of the potential browsers.

(Also note that they reprot 13% of people browsing without Javascript
<URL:http://www.thecounter.com/stats/2003/May/javas.php>)

Then check <URL:http://www.upsdell.com/BrowserNews/stat.htm> Four
different sources of statistics all place IE below 90% (some just).

Then remember that browser statistics are not trustworthy, because
browsers lie about who they are.

and the other 1% are used to having problems on the web ..

Not with the web as such. I would have many more problems if I used
IE, just a different kind (like people removing the context menu
or other annoyances that a browsers hould not allow).

/L

 

[Richard Cornford]

message

However, it worked with neither method with Opera
(I tried both).

The code you have written is too complex to attribute failure of the
operation to a fault in the browser. You need to demonstrate that a
problem exists in _isolation_ prior to attributing it to the browser.

Richard.

 

[Ekkehard Morgenstern]

The code you have written is too complex to attribute failure of the
operation to a fault in the browser. You need to demonstrate that a
problem exists in _isolation_ prior to attributing it to the browser.

See my dicussion with Lasse Reichstein Nielsen in this thread.

I already found a solution that simply does a function object
encapsulation of the handler routine call, and then it works:

var listener = function( Event ) { Code( Event ); }

weird, huh?!

But the code that I've written is fairly simple IMO, I'm surprised
that some JavaScript implementations have problems with it.

Why does "Code" alone not suffice? It's a function reference, as
required by the DOM standard.

Perhaps browsers like Opera check the object type, and if it's
not a function object, things don't work.

Whatever it is, I fixed it now for V0.0.6.

(V0.0.5 also works with Opera, but effectively doesn't use the
EventListener interface)

 

[Jim Ley]

Surpricing.

It shouldn't be surprising, it's only because the ECMAScript binding
doc is inconsistent with the definition, and the IDL. It's a dodgy
area.

http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-EventListener

Jim.