49

I was looking around to add an event to a checkbox and I would have thought people would use .change to set up a change event but instead I found that people are using .click

Is there a reason for this? They both seem to work fine both with clicked events and with keyboard changes. Am I missing something?

If you don't believe me then try it out yourself

qwertymk
  • 34,200
  • 28
  • 121
  • 184

5 Answers5

53

onchange in IE only fires when the checkbox loses focus. So if you tab to it, hit space a few times, tab out, you'll only get one onchange event, but several onclick events.

Note: this is one of the very, very, very rare times when IE's behavior is correct (according to spec) and other browsers are wrong.

  • also interesting didn't know you click things like that – mcgrailm Apr 07 '11 at 02:48
  • actually it works for clicks too. If you click the checkbox twice and then click somewhere else you won't get an `onchange` event (clicking it twice returns it to its initial value), but you'll get two `onclick` events. –  Apr 07 '11 at 02:49
  • Worth noting that onchange only fires when the focus changes in text fields - i wasn't aware that the behavior was different for checkboxes, but i suppose it's because their focus is not as well defined. – crazy2be Apr 07 '11 at 03:33
10

Two reasons why onclick is preferred over onchange.

  1. Internet Explorer only fires the onchange event when the checkbox loses the focus (onblur). So onclick is more of a cross browser solution.

  2. onchange happens only after the element lose focus.(You wont see a difference since you are calling alert and losing focus on every change). The pseudo code on MDC pretty much explains the element.onchange implementation.

    control.onfocus = focus;
control.onblur = blur;

function focus () {
    original_value = control.value;
}

function blur () {
    if (control.value != original_value)
        control.onchange();
}
mpen
  • 272,448
  • 266
  • 850
  • 1,236
naveen
  • 53,448
  • 46
  • 161
  • 251
0

.change doesn't work correctly for at least some popular browsers in relation to key changes (the user selecting option with up/down arrow keys) but then .click doesn't overcome this either. Sometimes the use of keyup or keydown or something is used in conjunction with .change to overcome this issue however it starts to get a bit messy when you user's tab the document as this can trigger the key event if it's not explicitly handled within the callback. All in all it's a shame that .change doesn't work as you would expect as it would solve some time consuming issues.

Rob
  • 10,004
  • 5
  • 61
  • 91
0

yes both work, only click does not look at the actual object changing (like a checkbox that gets checked), change does.

Technically it is more reliable but in practise both work.

cmplieger
  • 7,155
  • 15
  • 55
  • 83
0

They may both fire a change in the value by default, but you may override the onClick logic to NOT change the value of a chackbox. You may change the value via another entry point. So having a .click and a .change is needed.

edit - I also agree with Dr Rob

IEnumerable
  • 3,610
  • 14
  • 49
  • 78