Re: monitoring changes to an input
- I guess that's workable in a system where the input validation on the
client side is only of an advisory sort and the real input validation
must happen on the server because it's exposed to all the world's
script kiddies. It feels fast and loose to this old hand, though.
And speaking of old hands, maybe it's just the low-level system hacker
in me, but it seems a bit extravagant to be causing a script to be
interpreted several times a second. Maybe I'll do it anyway just to
enjoy the transgressive feel.
It seems we really do need a richer set of events, though. I have
heard that, historically, getting the various parties in W3C to see
eye-to-eye on such things has been quite a task. Nevertheless...
> Back in the days of Netscape Navigator 3 and Internet Explorer 3
> (before key events were invented) I achieved the same effect by using
> a setTimeout to check the value of the field. (Of course, now you
> would be better off using setInterval.)
> As the keypress events don't fire on paste, and (as you've found out)
> the change event only fires once the control loses focus, this might
> be your only cross-browser option.