Alert and Input Control Events

[Gene Wirchenko]

Dear JavaScripters:

Does using alert() cause input control events to fire?

I am writing some validation routines where I want the control to
keep the focus if the test fails. (Yes, I know that this is
desktop-app style. That is what I want.)

Actually, if onblur fires, the focus has already moved. To get
around this, I have a global that is set if validation is already
occurring on another input control. In that case, I simply bypass the
validation on the second control so that the focus can be set back.

This works (IE 9 & Windows 7).

It seems that the order of statements is important. I have to
set the focus back before generating the error alert. Otherwise, it
does not work right, and I can get the other input control's
validation routine getting in the way. I also had the hilarity of my
debugging alert() statements affecting the program flow.

It seems to me that alert() might cause input control events to
fire. Is this so? If so, is it guaranteed to be like this, or is it
just IE 9's implementation? How tied to implementation is this error
handling making my code?

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On Sat, 31 Dec 2011 01:27:32 +0100, Stefan Weiss

[snip]

A trivial (and admittedly construed) example where gluing the focus to
one particular field would be harmful is a 3-field date input: ^^^^^^^^^^^^^^^^^^
Yech!

[2011] [11] [30] (pre-filled values)

The user realizes that the correct value should be 2011-12-31, and
starts by changing the "day" field, entering "31". This results in a
temporarily invalid date - but they can't leave the "day" field to
adjust the "month" field. They will swear at the "stupid braindead app",
click away the alert, enter "30", change the month, and finally enter
"31" again.

I am referring to field-level validation, not form-level
validation. If a field value itself is invalid *without reference to
any other fields*, I will throw an error. In the above example,
entering a month 13 is such an error. Entering a day 32 is such an
error. Entering a day 31 is not such an error.

If the problem is that two or more field values are incompatible
(say, month 2 and day 30), that is a form-level error and I would
handle that on form submit.

The principle is to catch the error as soon as possible.

[snip]

Sincerely,

Gene Wirchenko

 

[Gregor Kofler]

Am 2012-01-01 08:40, Gene Wirchenko meinte:

I am referring to field-level validation, not form-level
validation. If a field value itself is invalid *without reference to
any other fields*, I will throw an error. In the above example,
entering a month 13 is such an error. Entering a day 32 is such an
error. Entering a day 31 is not such an error.

If the problem is that two or more field values are incompatible
(say, month 2 and day 30), that is a form-level error and I would
handle that on form submit.

Do you *really* want to use alert dialogs for such errors (and fiddling
with element focus)? Usability will be painful, to say the least. Even
more so, when there will be a second validation run upon submission
(with probably a different way to inform the user about errors). I'd opt
for blur listeners giving consistent feedbacks, and *not* fiddling with
element focus.

Gregor

 

[Evertjan.]

Gregor Kofler wrote on 01 jan 2012 in comp.lang.javascript:

Am 2012-01-01 08:40, Gene Wirchenko meinte:


Do you *really* want to use alert dialogs for such errors (and fiddling
with element focus)? Usability will be painful, to say the least. Even
more so, when there will be a second validation run upon submission
(with probably a different way to inform the user about errors). I'd opt
for blur listeners giving consistent feedbacks, and *not* fiddling with
element focus.

Perhaps it would be nicer to have each form-field giving a green flag if
correctly filled, not irritating the user with error messages at each
incorrect or empty field.

I however would usually prefer to do a single pre-submit validation,
clientside for speed and/or serverside for quality,
showing commented red flag warnings at each offending field.

 

[Gregor Kofler]

Am 2012-01-01 14:21, Evertjan. meinte:

I however would usually prefer to do a single pre-submit validation,
clientside for speed and/or serverside for quality,
showing commented red flag warnings at each offending field.

Indeed, that's how I frequently implement my form validation.

Gregor

 

[Gene Wirchenko]

Am 2012-01-01 08:40, Gene Wirchenko meinte:


Do you *really* want to use alert dialogs for such errors (and fiddling
with element focus)? Usability will be painful, to say the least. Even

Yes.

In your opinion. The existing app works that way and has for
years.

more so, when there will be a second validation run upon submission
(with probably a different way to inform the user about errors). I'd opt
for blur listeners giving consistent feedbacks, and *not* fiddling with
element focus.

Sincerely,

Gene Wirchenko

 

[Scott Sauyet]

     Yes.

     In your opinion.  The existing app works that way and has for
years.

Certainly it's Gregor's opinion. But it also reflects what I believe
to be a fairly widespread consensus in the web development community
that alerts should be reserved for those (likely few) cases where a
less intrusive approach simply won't work.

If the existing app is perfect, then there is no reason to replace
it. Otherwise, you might want to take the opportunity to rethink the
way it has worked for years. I'm not saying that you should
necessarily change it, but do consider the possibility.

-- Scott

 

[Gene Wirchenko]

On Tue, 3 Jan 2012 04:54:12 -0800 (PST), Scott Sauyet

[snip]

Certainly it's Gregor's opinion. But it also reflects what I believe
to be a fairly widespread consensus in the web development community
that alerts should be reserved for those (likely few) cases where a
less intrusive approach simply won't work.

If worse comes to worse, then I can rewrite to eliminate them.

If the existing app is perfect, then there is no reason to replace
it. Otherwise, you might want to take the opportunity to rethink the
way it has worked for years. I'm not saying that you should
necessarily change it, but do consider the possibility.

The reason that the app is being redone is not because of the UI.
It is because we need it to be more accessible to other programs.

Sincerely,

Gene Wirchenko