6

I recently asked a question and posted some code, to which a suggestion was to change my click handlers on a select box to change.

My question now is this: should I always use the Change handler -- or are there situations where Click would still be appropriate (Assume I would like cross-browser compatibility).

EDIT: Here's what I gather: For things like select boxes, Change IS the way to go. For simple things, like images, there is no change, so click is the way to go.

Charles Sprayberry
  • 7,741
  • 3
  • 41
  • 50
Dirk
  • 6,774
  • 14
  • 51
  • 73

2 Answers2

5

When it comes to form controls, such as text-inputs, select-boxes, check- and radiobuttons, then you should use the onChange-event. When it comes to other stuff, such as link, lists, containers etc, then you should definitely use click, since those items does not support the onChange-event.

PatrikAkerstrand
  • 45,315
  • 11
  • 79
  • 94
1

Click does not work x-broswer, IE does not respond to a select or option click. Change is the only option available.

Jaykumar Patel
  • 26,836
  • 12
  • 74
  • 76
redsquare
  • 78,161
  • 20
  • 151
  • 159
  • 4
    This is incorrect. IE does not fire the change event when expected. Most browsers fire the change event the moment the value of an element has changed. IE, however, only fires the change event if and only if the value has changed after the element has lost focus. Therefore, for cross-browser coding it is better to use click for drop down lists and keyup for text boxes for truly responsive applications. Otherwise, your users will have to click or tab off the element for your event handling to take place in the best browser known to man. – illvm Jul 27 '09 at 15:33
  • @illvm - that's exactly what I was trying to write; had to deal with this some time ago. – montrealist Jul 27 '09 at 15:38
  • @illvm. What rubbish. Option click events cant be bound in ie. Therefore you have select click which tells you when the user is about to select an option. What good is that to anybody? – redsquare Jul 27 '09 at 15:38
  • @illvm - I know of no implementation where a select click event would be used. Can you show me one. – redsquare Jul 27 '09 at 15:39
  • Hmm.. this is interesting debate, so I'll let it go for a little bit longer. – Dirk Jul 27 '09 at 15:40
  • What happens if a user uses keyboard arrows for the select. What to do with the 'click'? – redsquare Jul 27 '09 at 15:43
  • Also, click does not work in Safari.....more info http://stackoverflow.com/questions/472259/jquery-click-event-not-being-triggered-in-safari – redsquare Jul 27 '09 at 15:46
  • @redsquare, before you spread misinformation please try to at least back it up with some factual information. Here is some useful code that actually works in IE, which hooks a select element's click event, and extracts its value, text, as well as performs some other useful UI tasks. $('saved_widget_select').observe('click', function(){ var that = $('saved_widget_select'); $('save_name').value = that[that.selectedIndex].text; $('saved_widget_id').value = that.value; $('savesavebox').removeClassName('buttonDisabled'); }); – illvm Jul 27 '09 at 15:47
  • But it fires when you click the element to begin with. What is the point in that, and fails to fire in Safari. Again why would I want it – redsquare Jul 27 '09 at 15:48
  • it cannot be considered an x-browser solution. Therefore .change is the only option. – redsquare Jul 27 '09 at 15:50
  • Depending on how responsive you want the app to be and how much code you want to maintain you could hook event conditionally based on the browser. I don't really know of a way to simulate when an event will fire off hand so maybe in non-IE browsers hook change and in IE hook click. – illvm Jul 27 '09 at 15:50
  • why when I can just use .change....It makes no sense to use a non standard event when you have one that works across all browsers. Change works no matter if it is fired after blur or not. – redsquare Jul 27 '09 at 15:51
  • the browser detection you suggest is just way ott for this. Why go through the pain when .change is ready and waiting to be used! – redsquare Jul 27 '09 at 15:53
  • So what about a handler for an image? Should I use Change instead of click then too? (simple case) – Dirk Jul 27 '09 at 15:54
  • @redquare Because the change doesn't fire at the proper time on 40-50% of the global user base... – illvm Jul 27 '09 at 15:55
  • You can argue that ie is actually correct in its implementation. The user does not confirm the change until they leave the field. You dont pay for an item in a shop when you take it from the shelf. Your not actually liable until you leave the shop. – redsquare Jul 27 '09 at 16:00
  • Michael, images dont have a change. They have a click and a load. But the load is broken in ie after the first image has loaded. It works if you create a new image in js however. – redsquare Jul 27 '09 at 16:01
  • 2
    @redsquare It's not a "buy" event, it's a "change" event. The state of the object has changed, therefore the change event should fire. If I change the option in a select list and check its value immediately afterward its value is different from what it was before. The event should have fired then. – illvm Jul 27 '09 at 16:10
  • So do you want a change event to fire even when scrolling through the list on a keyboard. I have not changed at that point. I am simply scrolling the available options. You will end up with mess of client site code going down the route you suggest. I'm still waiting for one example of a site that uses a select click.... – redsquare Jul 27 '09 at 16:13
  • @illvm is correct, the `click` event will be fired on `select` albeit not consistently across browsers: http://stackoverflow.com/questions/10119793/why-does-firefox-react-differently-from-webkit-and-ie-to-click-event-on-selec And to redsquare, there is actually a use case for `click` on `select`: call `function()` each time an option is selected **even** if they are the same option, `change` cannot do it. The only way I found for this use case is to have a "fake" `select` using some library such as jQuery UI and trigger `click` on these fake `option` elements. – K Z Apr 15 '12 at 22:38