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=true; 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.

 

[Thomas 'PointedEars' Lahn]

<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=true; 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]

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

 

[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.continuebtn.disabled = false;
theform.otherbtns.disabled = false;
}
</script>
</head>
<body onload="mewantbuttons()">
<form NAME="theform">
<input NAME="continuebtn" type="button" class="btn" value="Continue"
onclick="if
(myform.p_name.value=='') alert('You must enter a name for the
folder');
else { this.disabled=true; 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]

[...] 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:

[...] 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.

[...] 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.

 

[Thomas 'PointedEars' Lahn]

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

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]

[...]
<head>
<script>
function mewantbuttons() {
theform.continuebtn.disabled = false;
theform.otherbtns.disabled = false;
}
</script>
</head>
<body onload="mewantbuttons()">
<form NAME="theform">
<input NAME="continuebtn" type="button" class="btn" value="Continue"
onclick="if
(myform.p_name.value=='') alert('You must enter a name for the
folder');
else { this.disabled=true; 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:

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.

 

[Roman]

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=true; 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.

Sory for the stupid question, but why are you disabling that button in
the first place ? If the user happens to click it again while the next
page is loading, the server validation will fail again.

To the point - since onload will not fire, how about a timer event to
enable the button few seconds after page has been re-rendered (i.e. Back
button pressed) ? Btw. you can save your user pressing the Back button
by sending "Location" in HTTP response header on failed server validation.

Roman

 

[Thomas 'PointedEars' Lahn]

Sory for the stupid question, but why are you disabling that button in
the first place ? If the user happens to click it again while the next
page is loading, the server validation will fail again.

I think this was an approach to reduce server load.

To the point - since onload will not fire, how about a timer event to ^^^^^^^^^^^^^^^^^^^^
enable the button few seconds after page has been re-rendered (i.e. Back
button pressed) ?

Because it cannot be detected if this event occurred.

Btw. you can save your user pressing the Back button by sending
"Location" in HTTP response header on failed server validation.

True. Therefore, it is better if the form is generated by a server-side
application. Redirection should be done so that this application can
recognize which input content was wrong or missing, and includes
information into the generated resource about those fields (marking
them in some way.) This allows for easier maintenance of the validator.

The best approach is to use the same application that is used for generating
the form, for server-side validation of the submitted data, so that in a
sense the form submits its data to its own document resource. No further
redirection would be necessary then, and maintenance would be a child's
play.


PointedEars

 

[Randy Webb]

Merennulli said the following on 3/24/2006 3:14 PM:

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

OK but it wasn't a flame as I would call one.

Randy, the problem here isn't that he doesn't understand, it's that he
has a different philosophical approach.

Thomas has a Theoretical Approach, mine is a Realistic Approach. The
difference is huge.

Thomas is looking at it from the perspective of the future and the unknown.

I disagree with that.

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.

Sure you can. I know, precisely, what devices are and are not allowed on
the Intranet I work on. If I don't, then I can't have security and
considering that our Intranet deals with 10,000+ peoples personal
information a day then security is paramount.

Just out of curiosity though. Do you use CSS in your pages? And, do you
test it without the CSS?

He also can't know if someone on the team has circumvented
him and got permission from "upstairs" to connect his latest
nonstandard toy.

That is one concern that I don't have to deal with. Call it a luxury if
you want. Even my CEO knows how I can behave when somebody does
something that they shouldn't do on the Intranet. And, the person who
"gives permission upstairs" will take a bounce downstairs faster than
you can read this. It has happened and it will probably happen again.

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.

I disagree but we are all entitled to our opinions.

 

[Merennulli]

Thomas,
You're right, I didn't think that through all the way. I guess he could
do it onunload, so while the user is going forward it fires, preparing
it for when they come back. This is why I like doing server side code,
you can tie down the interface to controlled points.

Randy,
That's more than a luxury, it borders on being a fantasy world. I've
worked in several IT environments, three of which where I was the
decision maker on application deployment and where the environment was
supposed to be controlled. I have friends in dozens of other IT
environments. No matter how draconian the management structure, I've
never seen or heard of one (other than yours) be able to maintain
absolute control over what will be allowed on the network. Yes, they
can require everything go through checkpoints, but when I've been in
that situation, it mean that we had to support the pet hardware of
influential individuals, it never meant that everyone met our stated
standards or support level. Real security problems such as personal
wireless hubs, yes, that can be barred, but I've never been in a
position that allowed me to tell the president his PDA can't be used to
access our intranet over the existing wireless network.

I hope you don't take offense, but it sounds like even your level of
control is a self deception and part of a BOFH mentality. You even
state "It has happened and it will probably happen again." While you're
referring to the fact that your control of the network is supported, it
also demonstrates that your environment is subject to these unexpected
devices. You're justified in not supporting the devices, since you have
support above you to penalize offenders, but how long before the bubble
bursts and whoever is "bouncing" people downstairs on your behalf isn't
there anymore? Even a CIO can't fire a CEO for naively undermining the
IT infrastructure.

I do use CSS in nearly everything I've done since 2002, including
intranet apps, and I do test for lack of support for CSS, Javascript,
and text only (not inclusive, since both lynx and links currently
support limited Javascript). That sort of testing should be second
nature to any web developer, it shouldn't be a burdon to be dumped at
the first available opportunity.

Even those who stick with our "controlled" environment to the letter
have found ways of breaking my predecessor's pages. He created a notice
mailing form in Visual Studio using grid layout, and didn't lock the
format down with CSS, so people who upped their browser font size were
unable to click in fields where the label ran right over the top of
them. There is no substitute for planning your pages out so they
degrade gracefully.

 

[Thomas 'PointedEars' Lahn]

Thomas,
You're right, I didn't think that through all the way. I guess he could
do it onunload, so while the user is going forward it fires, preparing
it for when they come back. This is why I like doing server side code,
you can tie down the interface to controlled points.

Not understood. I have never mentioned `onunload' regarding this, I
recommended `onsubmit' (instead of `onclick'). `onunload' code is executed
when one navigates away from the document or the window is closed. That
does not help here because you cannot re-enable the controls later if the
Back feature is used. There is no event to handle this, at least no
interoperable one that I know of.

Please reply to the posting you are referring to, and quote the minimum
of that. NetNews is thread-based, a public discussion displayed as a
tree structure; therefore, your current posting style, originating from
bulletin boards, is not wanted here.

<URL:http://jibbering.com/faq/faq_notes/pots1.html>


PointedEars

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/28/2006 11:17 PM:

Please reply to the posting you are referring to, and quote the minimum
of that.

Yes, please do.

NetNews is thread-based, a public discussion displayed as a tree structure;

Only if the UA you are using supports tree structures.

therefore, your current posting style, originating from bulletin boards,
is not wanted here.

The current posting style is not wanted, but where or what software they
use is irrelevant as long as they follow the requested norms of posting
here. To say that people who post from "bulletin boards" (GoogleGroups
is *not* a "bulletin board" though) is complete rubbish. This is an open
group and *anybody* is allowed to post here. So please stop telling
people that garbage.

<URL:http://jibbering.com/faq/faq_notes/pots1.html>

Nothing in that document says that "bulletin board posters" are not
wanted here.

 

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn said the following on 3/28/2006 11:17 PM:

Only if the UA you are using supports tree structures.

I'm also unfa,miliar with the name "NetNews". I first thought this was
referring to some web based Usenet gateway.

The current posting style is not wanted, but where or what software
they use is irrelevant as long as they follow the requested norms of
posting here.

He didn't say otherwise, but just gave his opinion about the cause of
the style. I would probably have vagered on it being caused by Google
Groups hiding the "reply with quote" button instead of making it the
default.

To say that people who post from "bulletin boards"
(GoogleGroups is *not* a "bulletin board" though) is complete
rubbish. This is an open group and *anybody* is allowed to post
here. So please stop telling people that garbage.

Reread. He didn't.
/L

 

[Randy Webb]

Lasse Reichstein Nielsen said the following on 3/29/2006 12:50 AM:

I'm also unfa,miliar with the name "NetNews". I first thought this was
referring to some web based Usenet gateway.


He didn't say otherwise, but just gave his opinion about the cause of
the style. I would probably have vagered on it being caused by Google
Groups hiding the "reply with quote" button instead of making it the
default.

Yes, that is the major flaw with Google Groups. If they changed the way
it quotes the only way you could tell it came from Google would be the
headers. But as it is, just seeing a post without being quoted is a
pretty good indication of Google Groups posting.

Reread. He didn't.

I had to read it three more times and two cups of coffee to read it a
different way. The first four times I read it I got the implication that
posting from a "bulletin board" is unwanted. I can see where it implies
the posting style and how Google might cause that behavior. He should
have been a little clearer in what he said though.

But for now, he can have the benefit of the doubt on it.

And, this quote is all over Usenet and could have been given or referred to:

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.
<URL: http://www.safalra.com/special/googlegroupsreply/ >

 

[Thomas 'PointedEars' Lahn]

AFAIK "displayed" does not necessarily mean "depicted". The tree structure
is created by Message-ID headers of postings, and References headers of
followups to contain them.

I'm also unfa,miliar with the name "NetNews". I first thought this
was referring to some web based Usenet gateway.

Not at all. NetNews (network news) is the UUCP/NNTP-based communication
medium, with Usenet, including this newsgroup, being a subset of it. It
would be equally correct, but not equally sufficient, to say that Usenet
is thread-based.

<URL:http://en.wikipedia.org/wiki/Usenet>

HTH

Regards,
(F'up2) PointedEars

 

[Merennulli]

Not understood. I have never mentioned `onunload' regarding this, I
recommended `onsubmit' (instead of `onclick'). `onunload' code is executed
when one navigates away from the document or the window is closed. That
does not help here because you cannot re-enable the controls later if the
Back feature is used. There is no event to handle this, at least no
interoperable one that I know of.

As I said: "so while the user is going forward it fires, preparing it
for when they come back."
My purpose in mentioning an "onunload" alternative is clear, even
without reading your prior post. Onunload fires as the page is being
exited, so changes it makes would only affect the cached version of the
page. When you hit the back button, you pull up the cached version of
the page (hence the lack of onload), which you already altered as you
left the page. It's not using the back button as an event, it's
preparing the page for when you go back to it.

Please reply to the posting you are referring to, and quote the minimum
of that. NetNews is thread-based, a public discussion displayed as a
tree structure; therefore, your current posting style, originating from
bulletin boards, is not wanted here.

My style of response comes from the fact that I made the apparently
false assumption that everyone here could follow a conversation without
everything repeated any time someone speaks.

There is no policy statement here of how I should post. I quote when
I'm responding to something specific, and I will respond without quotes
when I'm responding to larger sections that require you to have read
the previous post(s) in entirety. These off topic tirades are "not
wanted" as well.

And yes, as Randy suggested, I'm viewing this through Google Groups,
which displays previous posts right above responses, but any decent
mail or news client can sort by topic. I've been on mailing lists and
newsgroups for 8 years, and your insistence on your posting style is
your own preference, not the ubiquitous or official style of a
particular format.

Randy, thank you for your later response that took into account the
interface I'm using and requested I accommodate the structure of your
interface rather than dismissing my response as "not wanted". Needless
abrasiveness such as that "not wanted" is what kills online user
groups.