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

[Dan Allen]

On Mon, Aug 17, 2009 at 7:21 PM, Jim Driscoll <Jim.Driscoll at 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 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.


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.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090828/d5f2b997/attachment.html