1

So I have some html that looks like the following:

<div class='something unknown' id='something_unknown_1'>
  <button onClick='removeParent(self)'>Remove me and my parent div</div>
</div>
<div class='something unknown' id='something_unknown_2'>
  <button onClick='removeParent(self)'>Remove me and my parent div</div>
</div>

...and so on. How exactly would I reference the button that fired the onClick without knowing the id of the button? I would like to eventually have my removeParent(self) method look like:

buttonThatWasClicked.parent().remove();
Tadeck
  • 132,510
  • 28
  • 152
  • 198
Atrus
  • 788
  • 4
  • 13
  • 34
  • 1
    Inline javascript is evil. You should try to practice [unobtrusive javascript](http://en.wikipedia.org/wiki/Unobtrusive_JavaScript). – Paolo Bergantino Mar 22 '12 at 00:26
  • 1
    @PaoloBergantino: It is not evil. No need to be dogmatic about your preferences. –  Mar 22 '12 at 00:33
  • @amnotiam: Since when did recommending industry best practices turn into being "dogmatic about preferences"? The "evil" part was obviously tongue-in-cheek, but inline javascript is definitely something that should be avoided at all costs. – Paolo Bergantino Mar 22 '12 at 01:10
  • @PaoloBergantino: I don't see how saying *"should be avoided at all costs"* is much different from calling it *"evil"*, but calling it an *"industry best practice"* doesn't impress me. There are times when inline handlers are appropriate, and in fact beneficial. It's no more intrusive to add an `onclick` attribute than it is to add a class attribute for the purpose of hooking up a handler after the DOM is ready. –  Mar 22 '12 at 01:25
  • @amnotiam: inline javascript is wrong for many reasons, and there are really no valid scenarios nowadays where it is excusable to use. It is harder to maintain, harder to understand, prone to errors, and mixes behavior with structure. All of the above is not really an opinion but widely agreed upon. I'm not sure how else to say it without sounding like a condescending jerk, but it is what it is. – Paolo Bergantino Mar 22 '12 at 02:08
  • @PaoloBergantino: Yeah, I've heard all the highly generalized reasons before. Again, I'm not impressed. *"Harder to maintian"* is not an absolute. *"Harder to understand"* is not an absolute. *"Prone to errors"* is perhaps only if you don't understand the unique scope chain, and then is rare to experience an issue. *"Mixes behavior with structure"* is only an issue if you don't prefer it, and again, is no less true when you include other hooks for your JavaScript, like classes. –  Mar 22 '12 at 02:21
  • @amnotiam Thankfully I was not out to impress you, merely educate you. Oh well, I tried. – Paolo Bergantino Mar 22 '12 at 04:39
  • @PaoloBergantino: But you made no cogent points. Just more broad statements. Not sure how that could educate anyone, though it may persuade those who don't know any better. –  Mar 22 '12 at 05:22
  • @amnotiam nothing in our conversation leads me to believe you know better, but have fun writing bad code and justifying it with your nonsense. – Paolo Bergantino Mar 22 '12 at 05:37
  • @PaoloBergantino: Heh... *dogmatic* was clearly the right word. Listen, you're the one who made the blanket statement, and obviously you can't back it up. Programming is about understanding details and making decisions. People who can't deal with such subtlety take refuge under wide sweeping rules. If that's what you need, fine, but it's no reason to mislead others. –  Mar 22 '12 at 13:36
  • @amnotiam You are, unsurprisingly, confusing the fact that there are no subtleties to this issue and making, ironically, your own sweeping statement that my stance on this issue somehow reflects my stance on all other issues. It is very much black and white what is best and what is not here, there are no nuances to explore. Every corner case excusing inline javascript has been made largely obsolete by the new generation of browsers and is of little concern to a beginner, which the OP - and you - clearly are. – Paolo Bergantino Mar 22 '12 at 15:16
  • @PaoloBergantino: I made no reference to any other issue. I did say with respect to the inability to deal with subtleties *"If that's what you need..."*, where *"if"* clearly leaves the door open to the possibility that you may not always be as closed minded as you appear to be. Nevertheless, you've given no objective defense of your initial statement. Instead you prefer to call me a *"beginner"* merely because I don't agree with your opinion. Your apparent inability to engage in a civil discussion on a factual basis edifies my observations. And yes... there are nuances to explore. –  Mar 22 '12 at 16:29
  • @amnotiam What you seem to be unable to understand is that I do not have to defend my stance on this issue. My stance is the way that things are being done across the industry and **widely** agreed upon. The only position that must be defended is yours, which you have not even made an inkling of an attempt to do, instead choosing to make vague remarks about knowing something the rest of us don't. My guess? You just don't know what you're talking about. – Paolo Bergantino Mar 22 '12 at 17:03
  • @PaoloBergantino: What is my position to defend? That they can be used? What proof does that require? I'm certain you're already aware that inline handlers work across generally supported browsers. I wouldn't dare suggest otherwise. –  Mar 22 '12 at 17:31
  • @amnotiam Not that they *can* be used, but that they *should* - just because something works across browsers does not make it suitable for a task if there are better options out there. I can write `Hello World` on a site but won't because it is deprecated and there is a better alternative. Likewise, I won't be writing `onclick=` anytime soon because there is a better way to do it. – Paolo Bergantino Mar 22 '12 at 19:53
  • @PaoloBergantino: My position has never been that they *"should"* be used. That would imply that the alternatives should not. I'm just saying that they're a valid alternative, and that there are some actual benefits. I understand that you likely don't value those benefits, and that you won't use inline handlers on any occasion. That's obviously up to you and makes no difference to me. While I'd never argue that they're always the right solution, I must disagree with the statement that they should never be used. I don't see any justification for such a broad statement. –  Mar 22 '12 at 21:21

3 Answers3

10

You can use this to reference to the button that was clicked inside the click handler.

$("button").click(function(){
    removeParent($(this));
});

function removeParent(buttonThatWasClicked){
    buttonThatWasClicked.parent().remove();
}
driangle
  • 11,601
  • 5
  • 47
  • 54
4

I would add a class to the buttons so the function does not get bound to every button on the page only the ones you would like it to.

<div class='something unknown' id='something unknown'>
  <button class="myClass">Remove me and my parent div</div>
</div>
<div class='something unknown' id='something unknown'>
  <button class="myClass" >Remove me and my parent div</div>
</div>

Then use the jquery class selector to bind a function that removes the parent.

$(".myClass").click(function(){
    $(this).parent().remove();
});

Demo: http://jsfiddle.net/cXLqK/

Kevin Bowersox
  • 93,289
  • 19
  • 159
  • 189
  • @Atrus Lowest voted answer, but accepted. This is my favorite answer I have ever posted on SO. I'm guessing you didn't want to bind to every button? – Kevin Bowersox Mar 22 '12 at 14:59
4

If you have onclick on HTML nodes (i.e. not set via jQuery):

<div class='classA' id='idA'>
  <button onclick='removeParent(this)'>Remove me and my parent div</div>
</div>
<div class='classB' id='idB'>
  <button onclick='removeParent(this)'>Remove me and my parent div</div>
</div>

then this will work:

removeParent = function(e) {
    $(e).parent().remove();
}

Working example:

icyrock.com
  • 27,952
  • 4
  • 66
  • 85