Forums

Posting in these forums is disabled. These forums will be available for archive purposes. Please join the new forums at the links below:

  • yui-support - replaces the `YUI 3.x` and `YUI 3 Gallery` forums.
    We have created the following discussion categories within this group to aid discoverability for these most-used topics:
    • Charts for YUI Charts support.
    • DataTable for YUI DataTable support.
    • Gallery for YUI Gallery support, including support for published Gallery components as well as the Gallery process in general.
    • Tools for support of YUI’s suite of developer tools such as selleck, shifter, grover, yogi, etc.
    • Everything Else for questions that don’t fit one of the categories above, we’ve got you covered here.
  • yui-deprecated - replaces the `YUI 2.x` forum and the forums of other deprecated products (`YUI Doc`, `Builder`, `YUI PHP Loader`, etc.).
  [ 12 posts ] Go to page 1, 2 Next
New Topic | Post Reply | Print view
Previous topic | Next topic

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile
Tags:
  • container
  • element
  • event
  • selector

Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 2:12 pm
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!


cheers,
d

Adam Moore

YUI Contributor

  • Username: adam
  • Joined: Wed Sep 03, 2008 11:16 am
  • Posts: 356
  • GitHub: apm
  • Gists: apm
  • Offline
  • Profile

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 2:25 pm
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.

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 2:52 pm
I tried everything except 'this' within the callback function. Heh. Now I feel like a dork :P

Many many thanks for the heads up.

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 3:06 pm
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!

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 3:14 pm
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.

d

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile
Tags:
  • event

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 3:21 pm
Also, ye.stopPropagation( e ); didn't stop anything either.

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

Adam Moore

YUI Contributor

  • Username: adam
  • Joined: Wed Sep 03, 2008 11:16 am
  • Posts: 356
  • GitHub: apm
  • Gists: apm
  • Offline
  • Profile

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 5:34 pm
Can you provide a link to a complete implementation? stopPropagation() should work for this.

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile
Tags:
  • chrome
  • element
  • event
  • ff3
  • ie6
  • ie7
  • ie8
  • opera
  • safari

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 5:51 pm
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 ( :lol: ).

```

Thoughts?

David J Wallace

  • Username: danjah
  • Joined: Wed Jun 02, 2010 5:10 pm
  • Posts: 60
  • Location: Wellington, NZ
  • Offline
  • Profile

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Thu Jun 03, 2010 5:53 pm
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.

Caridy Patino

YUI Contributor

  • Username: caridy
  • Joined: Mon Dec 08, 2008 5:40 pm
  • Posts: 494
  • Location: Miami, FL
  • Twitter: caridy
  • GitHub: caridy
  • Gists: caridy
  • IRC: caridy
  • YUI Developer
  • Offline
  • Profile
Tags:
  • container
  • event
  • label
  • input
  • form
  • bubble

Re: Event propagation, delegation, or related, for YUI 2.8.1

Post Posted: Fri Jun 04, 2010 6:28 am
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:

Code:
<label><input id="abc" /> label for abc</label>


and

Code:
<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.

Best Regards,
Caridy
  [ 12 posts ] Go to page 1, 2 Next
New Topic | Post Reply | Print view
Previous topic | Next topic
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