When the click event handler is registered in the select element, I find very conflicting behavior in browsers. I created a jsfiddle demo . Here is what I see:
- Firefox 12 on OS X (10.7 Lion): An event fires when an item is clicked. Drop-down menu does not open for long, does not remain open. Keyboard actions do not generate click actions.
- Firefox 12 on Linux (Ubuntu Lucid): same
- Chome 19 on OS X: Interacting with a mouse or keyboard does not trigger a click event.
- Chrome 19 on Linux: the first mouse click expands the options, then clicks on either the still existing selection or the options, fires the click event.
- Safari 5.1.6 on OS X: like Chrome on Linux, the first click expands the parameters, and then clicks on the click event trigger options (unlike Chrome, Safari hides the select element when showing parameters).
- Android Browser (on Ice Cream Sandwich): The start event of a click trigger. Parameters remain visible after the event and can be pressed. Clicking on the parameters does not trigger another event.
- Chrome Beta for Android (Ice Cream Sandwich): Same as Android browser.
I would be happy if someone could tell me or point me to the standard, but I think this is not so useful as I watched directly that no one was following him. What I suspect is that it is an unusual thing that is trying to do that it is perhaps more common to listen to a change event instead. It's true? How about listening to clicks on parameters? I could not get this to work, but it could be a stupid mistake.
(To give a little more context, I am replacing the select element built on Google Closure goog.ui.Select , because this component beautifully mimics some desktops of the select desktop, especially Chrome, but it cannot perform full-screen rendering of the advanced options that you see in mobile browser. And the application previously listened to this goog.ui.Component.EventType.ACTION event, which has no analog signal anywhere, so I'm just trying to find a sequential replacement.)
philo source share