Toggle enable/disable form elements broken in IE

[joe t.]

Here's what to look at:
http://sawyer.thookerov.net/request/itrequest.php
(script file: http://sawyer.thookerov.net/request/request.js

The form works fine in Firefox. Clicking on certain elements enables or
disables other elements as intended. The visual refreshes and sends
focus as needed.

However, using IE6, the visual does not refresh unless the user clicks
away from the control element (eg. open area of page, or clicking one
of the still-dimmed elements that should be available). Is there a flaw
in my code, or is it IE? i've also tried this page with XHTML
compliance and that doesn't work.
http://sawyer.thookerov.net/request/itrequestx.php

Any ideas? Any help is appreciated.

[Michael Winter]

joe t. wrote:

[snip]

However, using IE6, the visual does not refresh unless the user clicks
away from the control element (eg. open area of page, or clicking one
of the still-dimmed elements that should be available).
In the HTML specification, and the DOM 2 Events specification, the
change event is defined in terms of control focus and value change,
not just the latter. Microsoft's interpretation could be deemed the
most correct, but hardly the most useful in terms of checkbox usage.

You can use the click event instead, though it does have problems in
at least one browser (though I think that was NN4, so not too much to
worry about).
Is there a flaw in my code, [...]

There is one: you shouldn't disable elements via HTML. If it's
possible for a user to arrive at your form without client-side
scripting support (a possibility on the Web), the form will be useless.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[joe t.]

It was indeed the event handler. onClick fixed it in IE and preserved
functionality in FF. Thanks for the tip. Can't really remember why i
went with the change handler in the first place... :-?

Also, i realize initializing form elements in a specified status isn't
good practice, but this is a strictly internal page that my boss wants
me to "dummy-proof" as much as i can. So i figure if the user can't
enter random data unless deliberately choosing to do so, that's
helpful. Can't win all battles, but it might prevent some.
-joe t.

[Michael Winter]

joe t. wrote:

[...] Can't really remember why i went with the change handler in
the first place... :-?
In principle, events like change are preferred as they don't imply any
device dependancy. However, click tends to be a synonym for activate
in most user agents.
Also, i realize initializing form elements in a specified status
isn't good practice, but this is a strictly internal page [...]

With internal stuff, you can get away with much more. However, that
only holds true if you know precisely what's being used, and how it is
set up.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.