new distribution in the works, and the addEvent contest over at quirksmode
Stephen Howard
DOM.createElement), and part of what i need is to use an addEvent-like
method for event registration. Currently on JSAN we have DOM.Events,
but as I've discovered it doesn't correctly handle the 'this' keyword in
callbacks (at least in my initial testing under firefox 1.5):
http://stephen.thunkit.com/_SCRIPTS/lib/create_before.html (plain old
element.onclick=foo)
http://stephen.thunkit.com/_SCRIPTS/lib/create_after.html (Using DOM.Events)
I'm sure many people are aware of the addEvent contest coming to a close
over at quirksmode.org, and that had me wondering something else. Which
is there are quite a few libraries out there that have a broad following
(cssQuery, DOJO, etc) that aren't represented on JSAN. Which means
they're kind of off limits for dependencies inside JSAN distributions, I
think. How can we convince the authors of these libraries, and the
addEvent contest winner, to add their code to JSAN?
-Stephen
Rob Kinyon
>
> I'm working on a new contribution to JSAN (tentatively called
> DOM.createElement), and part of what i need is to use an addEvent-like
> method for event registration. Currently on JSAN we have DOM.Events,
> but as I've discovered it doesn't correctly handle the 'this' keyword in
> callbacks (at least in my initial testing under firefox 1.5):
that includes both a test and the corrected code. That way, we have
the best possible implementation of whatever feature it is.
> I'm sure many people are aware of the addEvent contest coming to a close
> over at quirksmode.org, and that had me wondering something else. Which
> is there are quite a few libraries out there that have a broad following
> (cssQuery, DOJO, etc) that aren't represented on JSAN. Which means
> they're kind of off limits for dependencies inside JSAN distributions, I
> think. How can we convince the authors of these libraries, and the
> addEvent contest winner, to add their code to JSAN?
you were on here?" If they balk, do what I did with Prototype and
offer to convert it for them. It's really hard to say no to that ...
Rob
Dave Rolsky
>> I'm sure many people are aware of the addEvent contest coming to a close
>> over at quirksmode.org, and that had me wondering something else. Which
>> is there are quite a few libraries out there that have a broad following
>> (cssQuery, DOJO, etc) that aren't represented on JSAN. Which means
>> they're kind of off limits for dependencies inside JSAN distributions, I
>> think. How can we convince the authors of these libraries, and the
>> addEvent contest winner, to add their code to JSAN?
>
> Very simple - point them to JSAN and say "Hey, wouldn't it be cool if
> you were on here?" If they balk, do what I did with Prototype and
> offer to convert it for them. It's really hard to say no to that ...
it. My DOM.Ready library is based domFunction by "brother cake", though
it's entirely new code.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
Justin Constantino
Stephen Howard wrote:
> I'm working on a new contribution to JSAN (tentatively called
> DOM.createElement), and part of what i need is to use an addEvent-like
> method for event registration. Currently on JSAN we have DOM.Events,
> but as I've discovered it doesn't correctly handle the 'this' keyword in
> callbacks (at least in my initial testing under firefox 1.5):
>
> http://stephen.thunkit.com/_SCRIPTS/lib/create_before.html (plain old
> element.onclick=foo)
> http://stephen.thunkit.com/_SCRIPTS/lib/create_after.html (Using DOM.Events)
I'm the one who wrote DOM.Events.
The reason I didn't make 'this' refer to the handling element is
because the 'currentTarget' property of the passed event object already
gives you access to the element, and I don't see much of a point in
essentially having two names for the same variable.
'currentTarget' is specified in the W3C spec, while there's no mention
of the 'this' behavior at all, so 'currentTarget' seems to be a better
choice to me. I think the 'this' behavior in Mozilla and others is
just a carry-over from the old Netscape event model, and I'm not sure
it's a good idea to be writing event handlers that depend on the old
syntax..
ste...@enterity.com
I see your point, i just know there has been a lot of talk about the
'this' keyword in the current addEvent goings-on over at quirksmode, and
hadn't realized it wasn't in the spec.
Thanks for the reply, thanks for putting your code on JSAN for us.
-Stephen
Tom Metro
> Stephen Howard wrote:
>> DOM.Events...doesn't correctly handle the 'this' keyword in
>> callbacks...
>
> The reason I didn't make 'this' refer to the handling element is
> because the 'currentTarget' property of the passed event object already
>
> 'currentTarget' is specified in the W3C spec, while there's no mention
True, but the spec. does indicate that a DOM Level 2 EventListener is
expected to behave in the same way as an older style event handler property:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-registration-html40
...the setting of attributes which represent event handlers...behaves
in the same manner as any other EventListeners which may be registered
on the EventTarget.
In addition dispatchEvent() is shown to be a method of the EventTarget,
or DOM node receiving the event:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-EventTarget
and although there is another layer of indirection (dispatchEvent()
calling the handler), it still has a "method" feel and sets up an
expectation that there will be a 'this' keyword pointing to the EventTarget.
It seems unlikely that this behavior would go away in future
implementations of DOM Level 2 events (at least in JavaScript), so if a
goal of DOM.Events is to provide DOM Level 2 functionality on older
browsers, supporting 'this' in the expected way seems like a reasonable
requirement.
> ...and I don't see much of a point in essentially having two names
> for the same variable.
You could argue that it might be poor practice, but I could see simple
event handlers being created that never make use of the passed event
object (actually quite common in existing code) and only reference 'this'.
The place where things get messy in event handlers is that due to the
limitation of not being able to subclass DOM objects, you often see
event handlers implemented as methods of objects that contain DOM
objects. But because they are never actually called as a method of the
containing object, the use of 'this' can be misleading.
-Tom