Forums

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.

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.

Thanks again!

Also, ye.stopPropagation( e ); didn't stop anything either.

Code at: http://paste.dollyfish.net.nz/158650

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

Summary
``````````````
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 ( ).

```

Thoughts?

Hey David,

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:



and



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.

Best Regards,
Caridy