On 8/17/09 1:25 PM, Ed Burns wrote: > On Wed, 12 Aug 2009 14:27:37 -0700, Jim Driscoll<Jim.Driscoll(a)Sun.COM> >>>>>> said: >>>>>> >>>>> > JD> So, in the interests of making all browsers behave similarly, I've > JD> changed the default behavior to onclick for those components. > > I agree with this modification. I didn't see anything in the > ChangeLog[1]. Can you add it, please, Jim. > It's not a spec change - the spec doesn't specify exactly what behavior happens for the default event. This is by (good) design. I don't think we should specify any of this in the spec, but merely try our best to actually reflect a "valueChanged" event - however that may be. Jim, I'd still like to see your answer to Dan Allen's question about, > "can we manually emulate the real, onchange behavior by doing some kind > of old/new comparison". However, I must say that I don't personally > think the extra logic is worth it. > There are other issues about this, which I've been trying to look at today. I'd delayed answering because my research on it isn't complete. As a partial summary of what I've found: blur() won't work - it messes with accessibility. blur() would need to be followed by focus() - and now it's getting really messy - imagine the escape handling you'd have to code in to not spuriously call a user supplied onfocus handler. Though in all honesty, that may be the cleanest solution - if we really want one. The component's value is already changed in the actual (click) event itself, so you can't do any testing there. You could cache the complete value list (in some sort of body onload method *shudder*), but that's probably a bad idea too - and would fail on programmatic change of the selected values anyway (which is alarmingly common) - though that also causes a simple onchange handler to also fail on some browsers. You could also set up a timer that periodically checked for value changes, executing on, say, a 50 ms interval. That seems like a lot of bother to get around seeing an extra click on a radio button - but I suppose that would work. Of course, you'd be writing a bunch of code out into the rendered page - and that code could be vulnerable if you're doing ajax updates of those values, so you'd have to route it through there. And then you'd be spawning new executable code in JavaScript on a timer - probably one for each radio set, unless you really want to get fancy. I shudder to think of what that would do to an IE6 client on a slow machine, if they hit a page with a fair number of radio buttons. So, in short, no, it appears we can't (easily) fix this. It's broken. The best option will probably be to have slightly inconsistent behavior, that's at least *predictably* inconsistent in all environments. (I.e. - you'll get onclick behavior for things, and onchange behavior for others) Remember, onclick behavior is just fine for checkboxes - every check changes state anyway. So we're really just talking about radio buttons. Where submitting twice would matter - that's starting to sound pretty much list a vague edge case. SO it seems like we're stuck with what we currently have - it's minorly flawed, but not as flawed as every other way I can think of doing it.