«

"Ekkehard Morgenstern" <> writes:

> 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
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

"Lasse Reichstein Nielsen" <> wrote:
> 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.

"Ekkehard Morgenstern" <> writes:

> 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.
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

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



On Sat, 17 Jan 2004 20:47:34 -0500, Randy Webb
<> wrote:

>Ekkehard Morgenstern wrote:
>> "Janwillem Borleffs" <> wrote:
>>
>>>Take a look at Opera, the user can specify how this browser should identify
>>>itself.
>>
>>
>> Actually, for version 0.0.4, which I've just released, I had to work around
>> a specific Opera bug (non-standard JavaScript implementation that does not
>> conform to the ECMAScript 262 standard, unlike Netscape/Mozilla and Internet
>> Explorer). If the user changes the user agent string to omit "Opera", then
>> *poof* all sites using ISKEET will not load properly anymore. Tough luck, eh!
>
>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.
>
>> As soon as the Opera developers correct their JavaScript implementation
>> to conform to the standard (i.e. do proper parameter passing of objects
>> by reference), then I can lift the workaround for the new version.
>>
>> This would be impossible to detect without the HTTP UserAgent field,
>> and that's exactly what it's there for.
>
>if (window.opera){
>//opera code here.
>}
>
><sarcasm>
>Wait, I didn't check the userAgent string, I must have done it wrong.
></sarcasm>
>
>
>>
>>>It's not the user, but the vendor which may temper the user agent string
>>>because it's never a fixed value as a rule.
>>
>>
>> Then the user has to deal with the results. Many sites depend on the
>> UserAgent string, especially PHP sites, but also JavaScript sites.
>
>Then "many sites" are poorly written by amateurs posing as professionals
>that know what they are doing.
>
>>
>>>Per example, when the developers
>>>of the Mozilla browser decide to use "gecko" instead of "Gecko", your
>>>detection is broken.
>>
>>
>> Which will never happen, because then a lot of sites depending on this
>> will stop working. For example, PHP sites that generate optimized JavaScript
>> code for specific browser types.
>
>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.
>
>--
>Randy
>

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!

"Brynn" <> wrote:
> 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)

(Brynn) writes:

> 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
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

"Ekkehard Morgenstern" <> wrote in
message news:buhf4e$v11$...
<snip>
>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.

"Richard Cornford" <> wrote:
> 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)

On Tue, 20 Jan 2004 00:29:13 +0100, Lasse Reichstein Nielsen
<> wrote:

>"Ekkehard Morgenstern" <> writes:
>> var listener = new Array();
>> listener.handleEvent = Code;
>> element.addEventListener( eventtype, listener, false );
>>
>> it works on Netscape/Mozilla, whereas
>
>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-Le...-EventListener

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/