[jsr-314-open] FYI: onchange for radio and checkbox

[Jim Driscoll]

On 8/17/09 1:25 PM, Ed Burns wrote:
>>>>>> On Wed, 12 Aug 2009 14:27:37 -0700, Jim Driscoll<Jim.Driscoll at 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.

Jim