Posting in these forums is disabled. These forums will be available for archive purposes. Please join the new forums at the links below:
|Page 1 of 2||[ 12 posts ]||Go to page 1, 2 Next|
I have a situation where I have a container element with a listener on it, and no matter what is clicked - the container or its children - I need to reliably access the container element in the callback when the event is fired.
When I click on a nestedElement, currentTarget == nestedElement. -- this isn't what I want. Sure, parentNode is fine when I know the nesting depth is 1. In my case it could be 2, or maybe even more (<div id="container"><a><img /></a></div>).
So I tried delegation, using the * selector; ye.delegate('container', 'click', this.handleSelection, '*');, and where it works nicely when a nested element of any depth is selected, it surprised me when it did not fire at all when I selected the container itself. I figured maybe it might at least return the 'container' arg as just being itself.
Is the ability to return the 'container' arg as itself when it is itself clicked a configurable option? Is it possible? Is there another solution?
Many thanks for all help!
Don't use delegate -- a normal click listener will fire when the container or any child is clicked. The default context will be the container element, so you can use 'this' to refer to it in your callback.
I tried everything except 'this' within the callback function. Heh. Now I feel like a dork
Many many thanks for the heads up.
Ahhhh, ok, I remember in one of my many tests now - I basically used 'parentNode.parentNode' and it got me what I wanted at the time (ignoring depth differences).
But what I couldn't do was stop propagation -- I only want this event to fire once.
It's for a CSS class toggle, so as you can imagine the toggling isn't accurate when the element nesting depth is an even number...
I've just now thrown in a: ye.stopEvent( e ); within the callback function, to prevent propagation.
Sorry for the multiple posts...
I'm not *quite* there yet, as I only wanted the event to fire once the stopEvent(e) was fine until I found that it prevented default behaviour (preventDefault() called as part of the convenience method?). So my checkboxes are CSS style toggling correctly, but they're not checking, same for radios.
I then read here: viewtopic.php?p=9740 that return false; would prevent further propagation -- but that hasn't stopped anything
If it helps/is needed, I'm testing in IE6,7,8, FF3.5, Chrome.
Also, ye.stopPropagation( e ); didn't stop anything either.
Code at: http://paste.dollyfish.net.nz/158650
Can you provide a link to a complete implementation? stopPropagation() should work for this.
Wow, ok, I think I opened a can of worms. I've sussed out the high-level "What's Happening", but I haven't sussed out the all important "Why".
This link contains a basic testing page I started working in, instead of within the context of my app - just to try and replicate the questionable behaviour: http://www.codefinger.co.nz/_etc/yui/event_propagation_test.html
When assigning a 'click' event to a LABEL element, which contains nested markup, the assigned event is fired twice (or *something* occurs). When assigning it to other elements like a DIV or SPAN, the event only fires once (as expected).
I have tested this on WinXPSP3 within; Chrome, FF3.5.9, Opera9.6.3, Safari4.0.5(531.22.7), IE8, IE7, IE6.
The only browser which does *not* fire a second event, when the LABEL element is used, is IE6 ( ).
It should also be noted that this double-event-firing only occurs when a form element is nested within a label element.
I have other elements in my app, such as <img /> which function correctly within a label element.
I'm suspecting this is accessibility related, something to do with the expectations of what a label element should provide a user? No surprises this doesn't occur in IE6, if that's the case.
Labels are proxy elements, whatever happens in a label, will be replicated into the control associated to that label. Therefore, labels should not be used for controlling the user actions, instead you should listen for events on the associated controls.
There are two ways to define labels:
<label><input id="abc" /> label for abc</label>
<input id="abc" /><label for="abc">label for abc</label>
So, when you click on a label, the browser will always create a new event for the associated content.
For the first approach, once the second event is created and executed it bubbles up, and the fact that label is the container of the input implies that the label will receive a second click event, in this case the event created by the browser due the proxy nature of the label.
In the case of the second approach, we don't have any real problem because they are not nested, and every event bubbles up without conflicting each other.
Here is the label w3c info:
http://www.w3.org/TR/html401/interact/f ... edef-LABEL
About IE, my theory is that IE normalizes the content, transforming the initial markup (first approach) into a more formal markup (second approach), which is a technique that many browsers use.
|Page 1 of 2||[ 12 posts ]||Go to page 1, 2 Next|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum