On Mon, Aug 17, 2009 at 7:21 PM, Jim Driscoll
<Jim.Driscoll@sun.com> wrote:
On 8/17/09 1:25 PM, Ed Burns wrote:
On Wed, 12 Aug 2009 14:27:37 -0700, Jim Driscoll<Jim.Driscoll@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.
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.
Thanks for doing this research Jim. If nothing else, you should preserve this in an FAQ.
It reminds me how pathetic HTML/JavaScript is after all of these years (or perhaps just IE). You'd think that this stuff would have been fixed by now. If JSF can't solve the problem in a simple way, then perhaps would should just say it isn't JSF's concern. I suppose third party frameworks can put in all the interval checking they want.