button.disabled - firefox vs IE difference

[Jeremy]

Hi, say we have the code below on a button:

<input type="button" class="btn" value="Continue " onclick="if
(myform.p_name. value=='') alert('You must enter a name for the folder');
else { this.disabled=t rue; submit();}">

Not all the validation can be performed client-side so the button may be
pressed and then server validation is performed - this may result in a
request to the user to hit the back button and correct some data
entered.

Now this isn't the best UI design, I know. But nonetheless we have to
stick with this for a qhile and I have noticed a difference in the way
Fireforx and IE handles the button disbaling. On IE, when you go back to
the page, the button is enabled again whereas in Firefox it remains grey
and disabled.

Can anyone suggest a way in which we can automatically re-enable the
button when the user presses the back button? Is there some code we can
put into the onload perhaps which will go through all buttons on the
form and enable them?

Appreciate your suggestions.

--

jeremy

[Thomas 'PointedEars' Lahn]

Jeremy wrote:

<input type="button" class="btn" value="Continue " onclick="if
(myform.p_name. value=='') alert('You must enter a name for the folder');
else { this.disabled=t rue; submit();}">
This is nonsense, see below.
Not all the validation can be performed client-side so the button may be
pressed and then server validation is performed - this may result in a
request to the user to hit the back button and correct some data
entered.
And what would be wrong with this? Your application should be able to
handle that anyway.
Now this isn't the best UI design, I know. But nonetheless we have to
stick with this for a qhile
Not at all.
and I have noticed a difference in the way Fireforx and IE handles the
button disbaling. On IE, when you go back to the page, the button is
enabled again whereas in Firefox it remains grey and disabled.

Can anyone suggest a way in which we can automatically re-enable the
button when the user presses the back button? Is there some code we can
put into the onload perhaps which will go through all buttons on the
form and enable them?

No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without client-side
script support.

2. Use the `onsubmit' event handler of the `form' element, and do the form
validation there, by calling a validation function instead of this
badly maintainable spaghetti code. Return `true' to the handler if you
want the form to be submitted, `false' otherwise. Numerous examples of
this have been posted here before. Please do a minimum of research
before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has been
received from that client before, unless the server-side session timed
out, or was actively ended.
PointedEars

[Jeremy]

In article <12************ ****@PointedEar s.de>, Thomas 'PointedEars'
Lahn says...

No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without client-side
script support.

2. Use the `onsubmit' event handler of the `form' element, and do the form
validation there, by calling a validation function instead of this
badly maintainable spaghetti code. Return `true' to the handler if you
want the form to be submitted, `false' otherwise. Numerous examples of
this have been posted here before. Please do a minimum of research
before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has been
received from that client before, unless the server-side session timed
out, or was actively ended.

Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.

In the short term, as a hack fix (I make no bones about this), it would
meet my needs to be able to simply re-enable the button when the page is
redisplayed after a user has pressed the back button. I think from your
statement above " No. You /have to/ reconsider your design instead. " I
am right in understanding that you are saying that it is not a case of
it not being desirable but a case of it not being possible - is that so?

Thanks again

--

jeremy

[Merennulli]

While I'm of the opinion that you could rewrite your validation the way
he suggested in the time it takes to post here, I'll be nice and answer
the question as asked ;)

Your best bet is to enable the buttons by name, one after another, in a
simple onload script. If you're doing something quick and dirty, you
might as well. It will work, its just not the prettiest code or the
most efficient way to do it. You do need to name your button and form,
though, or referencing will be a real pain.

Something along the lines of:

<head>
<script>
function mewantbuttons() {
theform.continu ebtn.disabled = false;
theform.otherbt ns.disabled = false;
}
</script>
</head>
<body onload="mewantb uttons()">
<form NAME="theform">
<input NAME="continueb tn" type="button" class="btn" value="Continue "
onclick="if
(myform.p_name. value=='') alert('You must enter a name for the
folder');
else { this.disabled=t rue; submit();}">
</form>

----
That said, I agree with Thomas's assessment. It will take you very
little time to write your javascript cleanly to act onsubmit.
Also, I tend to avoid javascript validation myself. If the threat is
that they'd have to re-enter data, I have the server validation give
them their data back pre-filled in the form. The back button won't
always give them their data back, so you shouldn't rely on it.

[Thomas 'PointedEars' Lahn]

Jeremy wrote:

[...] Thomas 'PointedEars' Lahn says...

No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without
client-side script support.

2. Use the `onsubmit' event handler of the `form' element, and do the
form validation there, by calling a validation function instead of
this badly maintainable spaghetti code. Return `true' to the handler
if you want the form to be submitted, `false' otherwise. Numerous
examples of this have been posted here before. Please do a minimum
of research before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has
been received from that client before, unless the server-side session
timed out, or was actively ended.
Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.

It is not a question of the browser that is used. That the form would be
usable without client-side script support is a positive side effect of
proper design (using `onsubmit' instead of `onclick'). And who knows --
one member of your closed group might want to access the application with a
mobile device you do not know about yet that does not support client-side
scripting, or simply has it disabled because of some unnerving "features"
"provided" by a number of incompetent people on the Web.
[...] I think from your statement above " No. You /have to/ reconsider
your design instead. " I am right in understanding that you are saying
that it is not a case of it not being desirable but a case of it not
being possible - is that so?

Exactly.
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/24/2006 12:26 PM:

Jeremy wrote:

[...] Thomas 'PointedEars' Lahn says...

No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without
client-side script support.

2. Use the `onsubmit' event handler of the `form' element, and do the
form validation there, by calling a validation function instead of
this badly maintainable spaghetti code. Return `true' to the handler
if you want the form to be submitted, `false' otherwise. Numerous
examples of this have been posted here before. Please do a minimum
of research before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has
been received from that client before, unless the server-side session
timed out, or was actively ended. Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.

It is not a question of the browser that is used.

Do you continue to fail to comprehend what an IntrAnet is? Obviously you
do and keep trying to force everything into a square box when it's round.
That the form would be usable without client-side script support is a
positive side effect of proper design (using `onsubmit' instead of
`onclick'). And who knows -- one member of your closed group might
want to access the application with a mobile device you do not know
about yet that does not support client-side scripting, or simply has
it disabled because of some unnerving "features" "provided" by a number
of incompetent people on the Web.

Can you still not read plain English Thomas?

Let me quote it back to you, you quoted it yourself:

<quote>
The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.
</quote>

[...] I think from your statement above " No. You /have to/ reconsider
your design instead. " I am right in understanding that you are saying
that it is not a case of it not being desirable but a case of it not
being possible - is that so?

Exactly.

Exactly? Sure, Exactly Wrong.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 3/24/2006 12:26 PM:

Jeremy wrote:

Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.

It is not a question of the browser that is used.

Do you continue to fail to comprehend what an IntrAnet is?

You have yet to understand what an Intranet is, and that it does
not restrict its users to one user agent, especially not in the
mid-term. Probably you have never used an Intranet before. I have.
PointedEars

[Merennulli]

*Turns the fire hoses on.* Would be nice to do without the flames...

Randy, the problem here isn't that he doesn't understand, it's that he
has a different philosophical approach. Thomas is looking at it from
the perspective of the future and the unknown. Jeremy can't know if his
closed environment is about to have the doors opened to mobile devices,
or perhaps someone with a visual impairment gets hired to the team, and
the javascript doesn't work for his screen reader, or any other such
scenario. He also can't know if someone on the team has circumvented
him and got permission from "upstairs" to connect his latest
nonstandard toy. If that happens, all this time he's spent developing
QnD solutions (now, and each subsequent time) is wasted. Taking this
opportunity to do it right also makes maintenance in the future much
faster and simple.

I agree with Thomas's thinking on this, just because you believe your
environment is controlled, doesn't mean it really is, or that it will
stay that way. It's called being a conscientious programmer.

[Thomas 'PointedEars' Lahn]

Merennulli wrote:

[...]
<head>
<script>
function mewantbuttons() {
theform.continu ebtn.disabled = false;
theform.otherbt ns.disabled = false;
}
</script>
</head>
<body onload="mewantb uttons()">
<form NAME="theform">
<input NAME="continueb tn" type="button" class="btn" value="Continue "
onclick="if
(myform.p_name. value=='') alert('You must enter a name for the
folder');
else { this.disabled=t rue; submit();}">
</form>
[...]

Unfortunately(? ), your code (even if it was Valid) is not going to do what
it is intended to do. mewantbuttons() will not be called when the Back
feature is used because the `onload' code will not be called then. Not
even if you use Cache-Control in an attempt to prevent caching of the
resource (which is not recommended, though).

We discussed this before; there is no better solution than to drop the idea
of disabling the buttons completely, and to handle the problem on the
server.
Regards,
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/24/2006 1:04 PM:

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 3/24/2006 12:26 PM:

Jeremy wrote:
Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.
It is not a question of the browser that is used. Do you continue to fail to comprehend what an IntrAnet is?

You have yet to understand what an Intranet is, and that it does
not restrict its users to one user agent, especially not in the
mid-term.

Thank you for my daily laugh today Thomas.

What is, or is not, allowed on an intranet can be *very* controlled and
in most environments it is. The fact that you fail to realize that is
indication of your lack of comprehension of what I wrote.
Probably you have never used an Intranet before.
Really? I help manage an Intranet that is larger than your feeble mind
could possibly comprehend. And you know what? I can tell you *precisely*
what UA's are on it and what is and is not allowed on it.
I have.

Logging on at school to do your homework does not count.
--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/