Loading ...
Sorry, an error occurred while loading the content.

Re: monitoring changes to an input

Expand Messages
  • integerpoet
    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
    Message 1 of 6 , May 30, 2007
    • 0 Attachment
      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...

      --- In ydn-javascript@yahoogroups.com, Nick Fitzsimons <nick@...> wrote:

      > 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.
    Your message has been successfully submitted and would be delivered to recipients shortly.