[thelist] IE Field Tip

[Jeff Howden]

joshua,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Joshua Olson
>
> Respectfully, I disagree.  For the life of me I cannot
> reason why utilizing the onblur could be considered
> "poor programming."
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

because it's use in a scenario that involves the focus() method is asking
for trouble.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Here are a couple scenarios in which it would be
> practical to use it:
>
> [snip first two examples]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

these are both valid and reasonable uses for the onblur event handler.  i've
even found myself using it for these sorts of things in the past.  notice
that neither one of these makes use of the focus() method to
programmatically move the cursor into a field.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> 3.  The client would like the data checked for validity
>     everytime a value in a particular field is updated
>     and their off-the-wall browser doesn't fire the
>     onchange even when they paste a value into the
>     field or "undo" an edit in a field.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

this is what the onchange and onpropertychange event handlers are for,
especially if any of this validation statements involve the use of the
focus() method.  if so, you're opening yourself up for some nasty problems.

the first of these problems is the infinite loop i mentioned, which isn't as
easily avoided as you might initially think.  the second is premature data
validation when the user toggles the active window to another window on
their computer.  they haven't finished the data, yet the act of toggling the
window incorrectly assumes they are done.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Bottom line, given a set of tools, I'm not going to
> discount certain tools just because it's _possible_ to
> abuse them.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

that wasn't my reasoning.  i discounted onblur for the reason you were using
it because it's the wrong tool for the job.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Onblur has its uses, just as does every other function
> in the javascript arsenal.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

agreed.  you pointed out two very good uses for it too.  however, your use
of it for data validation (especially if the focus() method is involved) is
not a good use for it.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Responsibility is the key, not dogmatic and insulting
> rules that pronounce that anybody that uses certain
> tools is a "poor programmer."
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

that's not what i said.  i said that using it was poor programming.  i
wasn't trying to make this debate personal.  i'll agree that my initial
broad-sweeping comment about the onblur event handler was alittle too
all-encompassing.  there *are* good uses for it.  however, good uses don't
get the focus() method involved or try to mimic the onchange event handler
when it's available and gets the job done.  your stumbling block is how to
validate data that is entered into a field as a result of autocomplete.
you've had the answer, onpropertychange, handed to you.  yet you continue to
want to use the onblur event handler for something it's not only not good
at, but also holds many dangers.

just my 2¢,

.jeff


——————————————————————————————————————————————————————
Jeff Howden - Web Application Specialist
Résumé - http://jeffhowden.com/about/resume/
Code Library - http://evolt.jeffhowden.com/jeff/code/