Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #8651
| Message-ID | <4794912.ypaU67uLZW@PointedEars.de> (permalink) |
|---|---|
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
| Organization | PointedEars Software (PES) |
| Date | 2011-11-26 12:51 +0100 |
| Subject | Re: <ul><li><ul><li>... onclick() only for one node ? |
| Newsgroups | comp.lang.javascript |
| References | <9j9pfhFe3lU1@mid.individual.net> <jaommj$c2$1@dont-email.me> <2194421.p0D5BbiEc1@PointedEars.de> <japa23$krr$1@speranza.aioe.org> |
| Followup-To | comp.lang.javascript |
Followups directed to: comp.lang.javascript
J.R. wrote:
> On 25/11/2011 17:28, Thomas 'PointedEars' Lahn wrote:
>> Jukka K. Korpela wrote:
>>> 2011-11-25 17:10, Jörg Weule wrote:
>>>> at<ul><li><ul><li>...</li></ul></li></ul> I got the click event on the
>>>> whole tree and want to process the event for only on one node.
>>>
>>> Applying the techniques explained at
>>> http://www.quirksmode.org/js/events_order.html
>>> you could write
>>>
>>> var l = document.createElement("li");
>>> l.onclick = handler;
>>> function handler(e)
>>> {
>>> if (!e) var e = window.event;
>>
>> That `VariableDeclaration' is pointless; it also reduces runtime
>> efficiency slightly. The Variable Object (or the Variable Environment)
>> already had the variable `e' instantiated per the function's argument
>> list, so the VariableDeclaration has no effect (other than checking for a
>> previous binding, which is what reduces runtime efficiency). [ES 5.1,
>> section 10.5]
>
> ACK as to 'VariableDeclaration is pointless', although that reduction in
> runtime efficiency, if noticeable / measurable, should be dependent on
> the actual JavaScript Engine in use.
There are only two JavaScript engines (in different languages and versions).
Whether the difference is noticeable depends not only on the ECMAScript
implementation. However, a conforming implementation must implement that
algorithm one way or the other, so there is without doubt a reduction in
runtime efficiency.
>>> e.cancelBubble = true;
>>> if (e.stopPropagation) e.stopPropagation();
>>> // do the real handling here
>>> }
>>
>> One should *either* attempt to set the `cancelBubble' property to `true'
>> *or* attempt to call the stopPropagation() method, depending on what is
>> the result of a feature test, because `e' refers to a host object and
>> should not be accidentally augmented. To that end,
>> jsx.dom.createEventListener() solves this with
>>
>> e2.stopPropagation = (function(e) {
>> if (jsx_object.isMethod(e, "stopPropagation"))
>> {
>> return function() {
>> e.stopPropagation();
>> };
>> }
>>
>> if (typeof e.cancelBubble != "undefined")
>> {
>> return function() {
>> e.cancelBubble = true;
>> };
>> }
>> })(e);
>
> "Either cancelBubble property or stopPropagation() method" means only
> one check is necessary, not both, as there is not a 3rd option.
You are mistaken.
> So:
>
> e2.cancelPropagation = function (e) {
> e = e || window.event;
Inefficient and error-prone.
> if (typeof e.stopPropagation !== 'undefined') { // W3C standard
Error-prone and insufficient.
> e.stopPropagation();
> } else { e.cancelBubble = true; } // IE
> };
That would augment the host object referred to by `e' if it did not have a
`cancelBubble' property.
>> `e2' is a reference to a native user-defined object that is passed in
>> place of the event host object (referred to by `e') to the wrapped event
>> listener then (revision 233, line 459):
>>
>> return f.call(this, e2);
>>
>> Which allows to call e.stopPropagation() in the wrapped listener (f)
>> regardless which DOM implementation is supported.
>>
>> A similar wrapper method exists for the preventDefault() method. But it
>> turns out that the `returnValue' property, which is the proprietary
>> replacement for the preventDefault() method, cannot be feature-tested.
>> So `returnValue' is used if preventDefault() is unavailable regardless.
>
> someObj.cancelDefault = function (e) {
> e = e || window.event;
Inefficient and error-prone.
> if (typeof e.preventDefault !== 'undefined') { // W3C standard
Error-prone and insufficient.
> e.preventDefault();
> } else { e.returnValue = false; } // IE
> };
You are missing the point, which is that an exception to the rule must be
made with this property. Your "IE" also is an oversimplification. You
would have known all this had you read my postings in this thread more
carefully.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
Back to comp.lang.javascript | Previous | Next — Previous in thread | Find similar | Unroll thread
<ul><li><ul><li>... onclick() only for one node ? Jörg Weule <weule@7b5.de> - 2011-11-25 16:10 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Arno Welzel <usenet@arnowelzel.de> - 2011-11-25 17:30 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-25 17:58 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Jörg Weule <weule@7b5.de> - 2011-11-25 18:42 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Martin Honnen <mahotrash@yahoo.de> - 2011-11-25 19:11 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Jörg Weule <weule@7b5.de> - 2011-11-25 19:37 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-25 20:04 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-25 20:27 +0200
Re: <ul><li><ul><li>... onclick() only for one node ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-25 20:28 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-25 21:57 -0200
Re: <ul><li><ul><li>... onclick() only for one node ? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-26 09:14 +0200
Re: <ul><li><ul><li>... onclick() only for one node ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-26 12:53 +0100
Re: <ul><li><ul><li>... onclick() only for one node ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-26 12:51 +0100
csiph-web