A question came up at work from one of our clients about forms on their
site.
The data from these forms are processed by a PHP script and if all goes
well, a thank you screen appears. Sometimes, when you go back to the form
(by clicking the back button), the data is still there in the form fields.
Other times it is not. The client would like to ensure the data remains, as
they sometimes have multiple submissions to make with similar entries.
There is client-side validation (JavaScript) on the forms, but other than
that, nothing else special about them.
Is there a way to ensure the values in the fields remain on return, or is
this just a quirk in browsers? The most commonly used browsers are IE & NN.
I would include a link to the form in question, but it is a request form for
a gubernatorial service (sent directly to the Gov's office), and I'd hate to
see them receive bogus requests.
Thanks.
--
SamMan
Rip it to reply
65  4410 
SamMan wrote: The client would like to ensure the data remains, as
they sometimes have multiple submissions to make with similar entries.
This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser. However, if
a problem is encountered and an error is found by checking it with PHP,
you should be able to reconstruct the form and fill in the values, all
using PHP. The user shouldn't have to depend on a feature his/her
browser might not have.
There is client-side validation (JavaScript) on the forms, but other than
that, nothing else special about them.
JS validation is ok, but most defiantly should not be relied on.
--
Michael Wilcox, http://mikewilcox.t35.com/
On Fri, 30 Apr 2004, Michael Wilcox wrote: This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser.
right...
However, if a problem is encountered and an error is found by
checking it with PHP, you should be able to reconstruct the form and
fill in the values, all using PHP. The user shouldn't have to depend
on a feature his/her browser might not have.
Good answer. The same is true for other server-side scripting, though
- it's not limited to PHP: for example the CGI.pm module makes this
quite straightforward in Perl with CGI. There is client-side validation (JavaScript) on the forms, but other than
that, nothing else special about them.
JS validation is ok, but most defiantly should not be relied on.
Oh, most "defiantly" true ;-) SCNR.
js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.
[1] where "fully" is defined by the requirements of the application.
hth
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk... On Fri, 30 Apr 2004, Michael Wilcox wrote:
This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser.
right...
However, if a problem is encountered and an error is found by
checking it with PHP, you should be able to reconstruct the form and
fill in the values, all using PHP. The user shouldn't have to depend
on a feature his/her browser might not have.
Good answer. The same is true for other server-side scripting, though
- it's not limited to PHP: for example the CGI.pm module makes this
quite straightforward in Perl with CGI.
There is client-side validation (JavaScript) on the forms, but other
than that, nothing else special about them.
JS validation is ok, but most defiantly should not be relied on.
Oh, most "defiantly" true ;-) SCNR.
js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.
[1] where "fully" is defined by the requirements of the application.
hth
Thanks to both of you for your advice. I kind of thought it was a browser
specific feature.
I agree that JavaScript (JS) isn't generally the best tool, but in this
case, I think it works. The form(s) just takes the form data and sends it to
an e-mail account(s), and is never processed any further (database, etc.).
The JS just basically checks for null values and formatting, so when the
data is sent to the person in charge of the ceremonies, it is clear & makes
sense to them. I also have it so if the end-user has JS disabled, the submit
button is also disabled. I wrote the backend to replace a Pearl script that
our agency was not allowed to alter (working for state agencies is fun!),
and made it hard to manage & alter. Also, the person really in charge of the
forms (and site) is a "veteran" of 10 years in web dev that can't even write
simple JS. I wanted to do all of the validation server-side, but couldn't,
as I had to keep it as simple as possible for the co-worker.
Thanks again!
--
SamMan
Rip it to reply
Alan J. Flavell wrote: Oh, most "defiantly" true ;-) SCNR.
Damn you convenient spell checker! *sigh* It's my own fault, but whatever...
Seems I'm not the only one. In
<http://www.w3.org/TR/AERT#color-contrast> I found, "The rage for color
brightness difference is 125. The range for color difference is 500."
Hmmm, I think the rage should be a little higher ;-)
js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.
[1] where "fully" is defined by the requirements of the application.
A while ago I found a document saying that forms should be processed so
that users can enter info in a variety of formats and it will be parsed
correctly. The example of a phone number was given, and how so many
formats are used and how users shouldn't be restricted to three little
boxes for the numbers. (I was thinking it was a Korpela article, but I
couldn't find it.)
--
Michael Wilcox, http://mikewilcox.t35.com/
SamMan wrote: I also have it so if the end-user has JS disabled, the submit
button is also disabled.
What good is that? How would I ever submit my form if my JS is off? Or
if I don't even have it?
--
Michael Wilcox, http://mikewilcox.t35.com/
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote:
I also have it so if the end-user has JS disabled, the submit
button is also disabled.
What good is that? How would I ever submit my form if my JS is off? Or
if I don't even have it?
--
Because, like I said... the JS is only used to check for null values and/or
formatting of the fields. If JS is disabled, the form can be submitted with
all blank fields. The client does not want this. Just because JS is
disabled, doesn't mean the form submit button won't work.
--
SamMan
Rip it to reply
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... Alan J. Flavell wrote:
Oh, most "defiantly" true ;-) SCNR.
Damn you convenient spell checker! *sigh* It's my own fault, but
whatever...
Seems I'm not the only one. In
<http://www.w3.org/TR/AERT#color-contrast> I found, "The rage for color
brightness difference is 125. The range for color difference is 500."
Hmmm, I think the rage should be a little higher ;-)
js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.
[1] where "fully" is defined by the requirements of the application.
A while ago I found a document saying that forms should be processed so
that users can enter info in a variety of formats and it will be parsed
correctly. The example of a phone number was given, and how so many
formats are used and how users shouldn't be restricted to three little
boxes for the numbers. (I was thinking it was a Korpela article, but I
couldn't find it.)
--
That is why I try and use regex whenever possible. :-)
--
SamMan
Rip it to reply
SamMan wrote: Just because JS is disabled, doesn't mean the form submit button won't work.
I'll answer that with a quote from you: "I also have it so if the
end-user has JS disabled, the submit button is also disabled."
Does this mean that if I have my JS off, I can't submit your form?
--
Michael Wilcox, http://mikewilcox.t35.com/
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote:
Just because JS is disabled, doesn't mean the form submit button won't
work.
I'll answer that with a quote from you: "I also have it so if the
end-user has JS disabled, the submit button is also disabled."
Does this mean that if I have my JS off, I can't submit your form?
--
Yes... and only because I have coded it so. Without the code I wrote, if the
user has JS disabled, the submit button still functions.
--
SamMan
Rip it to reply
SamMan wrote: Yes... and only because I have coded it so. Without the code I wrote, if the
user has JS disabled, the submit button still functions.
That's a poor choice. The user's browser may not have JS, or it may be
turned without the intention of turning it on again. Some people turn it
off for good reason, and it's a pain to turn it back on just to do
something like this. Like I said before, it's really better to do the
regex stuff with PHP.
Can I ask how you accomplish preventing the browser from submitting?
--
Michael Wilcox, http://mikewilcox.t35.com/
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote: Yes... and only because I have coded it so. Without the code I wrote, if
the user has JS disabled, the submit button still functions.
That's a poor choice. The user's browser may not have JS, or it may be
turned without the intention of turning it on again. Some people turn it
off for good reason, and it's a pain to turn it back on just to do
something like this. Like I said before, it's really better to do the
regex stuff with PHP.
Can I ask how you accomplish preventing the browser from submitting?
--
I agree that it would be better to do all error checking on the server, but
like I have stated before, I have to accommodate the developer who has
little to no experience in JS, let alone anything that happens on the server
side. They are the one who has "official" control over the site, and as
such, things must be done to make it easier for them... one of the pitfalls
of working for a government agency.
I do have to disagree with you on your point that it is a pain to turn on,
or enable JS. I generally use IE, and can disable/enable JS in a matter of
seconds.
How I accomplish the disabled button is I have a JS function that returns a
functional button. If JS is disabled, I have a disabled button wrapped
inside noscript tags.
--
SamMan
Rip it to reply
SamMan wrote: How I accomplish the disabled button is I have a JS function that returns
a functional button. If JS is disabled, I have a disabled button wrapped
inside noscript tags.
What happens when a user hits return? A button isn't the only way to submit
a form...
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote: Yes... and only because I have coded it so. Without the code I wrote, if
the user has JS disabled, the submit button still functions.
That's a poor choice. The user's browser may not have JS,
<snip>
What browser does not have JS? On my workstation, I have IE, NN (4 & 7),
Mozilla, Opera... all of them have JS, and it is enabled by default. This is
on a PC. I have also tested on Mac IE and Safari, both with JS.
--
SamMan
Rip it to reply
"Sherm Pendley" <sp******@dot-app.org> wrote in message
news:e8********************@adelphia.com... SamMan wrote:
How I accomplish the disabled button is I have a JS function that
returns a functional button. If JS is disabled, I have a disabled button wrapped
inside noscript tags.
What happens when a user hits return? A button isn't the only way to
submit a form...
sherm--
Nothing. The form is not submitted.
--
SamMan
Rip it to reply
SamMan wrote: I agree that it would be better to do all error checking on the server, but
like I have stated before, I have to accommodate the developer who has
little to no experience in JS, let alone anything that happens on the server
side. They are the one who has "official" control over the site, and as
such, things must be done to make it easier for them... one of the pitfalls
of working for a government agency.
Could you write the necessary PHP code? Would "they" allow it?
And since you brought up the government, I'll quote a government
document. Section 508 <http://www.access-board.gov/sec508/guide/act.htm>
requires all government webpages to comply with its regulations, one of
which reads, "When electronic forms are designed to be completed
on-line, the form shall allow people using assistive technology to
access the information, field elements, and functionality required for
completion and submission of the form, including all directions and
cues." Most assistive technologies are incapable of rendering JS, and
they therefore render what is in the noscript element. At your page,
this is their only option, and they can never submit the form, which
contradicts these regulations.
I do have to disagree with you on your point that it is a pain to turn on,
or enable JS. I generally use IE, and can disable/enable JS in a matter of
seconds.
Well, IE is certainly not the only browser used, and the conditions you
work in aren't the same as everyone else's. Someone may be accessing the
page on a library, school, or company computer which may have JS
disabled for security reasons. Or, like I stated earlier, they may have
an assistive technology which simply doesn't have the option of JS.
--
Michael Wilcox, http://mikewilcox.t35.com/
SamMan wrote: What browser does not have JS?
Assistive technologies, like JAWS, HomePage Reader, Lynx, Links, and
w3m, as well as anyone who has chosen to disable their JavaScript.
--
Michael Wilcox, http://mikewilcox.t35.com/
SamMan wrote: I also have it so if the end-user has JS disabled, the submit button is
also disabled.
This is trouble waiting to happen. A relatively large number of users keep
Javascript off for most sites, and this will ensure your form is useless
for them.
What part of "World Wide Web" is so hard to understand?
--
Shawn K. Quinn
SamMan wrote: "Michael Wilcox" wrote...
SamMan wrote:
I also have it so if the end-user has JS disabled, the submit
button is also disabled.
What good is that? How would I ever submit my form if my JS is off?
Or if I don't even have it?
Because, like I said... the JS is only used to check for null values
and/or formatting of the fields.
That should be done server side. It is extremely user-unfriendly to
require a technology that may not even be available to them. The only
assumption an html author can make is that the client has a reasonably
conforming html ua. Use .js only as an add-on.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
"Sherm Pendley" <sp******@dot-app.org> wrote: What happens when a user hits return? A button isn't the only way to
submit a form...
SamMan <sa*@psfdevrip-it.com> wrote: Nothing. The form is not submitted.
Let's try again.
What happens if the user submits the form anyway, even though you've tried
to prevent them from doing so?
Perhaps they use normal browser functions. Hitting the Enter key is one way
that browsers allow the user to submit a form without the submit button.
Perhaps they edit your form, add a submit button, and submit the edited
version of the form. It isn't hard to do if you know what you're doing.
And given the relationship between your site and the government, you may be
legally required to provide non-JavaScript functionality.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"Warning: Dates in the calendar are closer than they appear."
On Sat, 01 May 2004 01:57:27 GMT, "SamMan" <sa*@psfdevrip-it.com> wrote: "Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote: > Yes... and only because I have coded it so. Without the code I wrote, ifthe > user has JS disabled, the submit button still functions.
That's a poor choice. The user's browser may not have JS,
<snip>
What browser does not have JS? On my workstation, I have IE, NN (4 & 7),
Mozilla, Opera... all of them have JS, and it is enabled by default. This is
on a PC. I have also tested on Mac IE and Safari, both with JS.
Perhaps you would consider the points raised in http://www.xs4all.nl/~sbpoley/webmatters/whatnojs.html
--
Stephen Poley http://www.xs4all.nl/~sbpoley/webmatters/
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote:
I agree that it would be better to do all error checking on the server,
but like I have stated before, I have to accommodate the developer who has
little to no experience in JS, let alone anything that happens on the
server side. They are the one who has "official" control over the site, and as
such, things must be done to make it easier for them... one of the
pitfalls of working for a government agency.
Could you write the necessary PHP code? Would "they" allow it?
No, I have inquired already...
And since you brought up the government, I'll quote a government
document. Section 508 <http://www.access-board.gov/sec508/guide/act.htm>
requires all government webpages to comply with its regulations, one of
which reads, "When electronic forms are designed to be completed
on-line, the form shall allow people using assistive technology to
access the information, field elements, and functionality required for
completion and submission of the form, including all directions and
cues." Most assistive technologies are incapable of rendering JS, and
they therefore render what is in the noscript element. At your page,
this is their only option, and they can never submit the form, which
contradicts these regulations.
A sightless person has tested the forms and was able to fill out & submit
them.
"Darin McGrew" <mc****@stanfordalumni.org> wrote in message
news:c6**********@blue.rahul.net... "Sherm Pendley" <sp******@dot-app.org> wrote: What happens when a user hits return? A button isn't the only way to
submit a form...
SamMan <sa*@psfdevrip-it.com> wrote: Nothing. The form is not submitted.
Let's try again.
What happens if the user submits the form anyway, even though you've tried
to prevent them from doing so?
Perhaps they use normal browser functions. Hitting the Enter key is one
way that browsers allow the user to submit a form without the submit button.
Perhaps they edit your form, add a submit button, and submit the edited
version of the form. It isn't hard to do if you know what you're doing.
And given the relationship between your site and the government, you may
be legally required to provide non-JavaScript functionality.
--
If the user succeeds in submitting a form, a blank submission would be sent
to an e-mail address and ignored. I understand you're point, but if a person
goes to the trouble of editing the form to submit a blank one, all they will
have succeeded at is sending a form that will be ignored.
You do bring up a good point about non- JS functionality that I can use in
my defense of doing the error checking backend.
--
SamMan
Rip it to reply
On Sat, 1 May 2004, SamMan wrote: If JS is disabled, the form can be submitted with all blank fields.
With respect: reading the thread before and after this posting of
yours, you seem to have contradicted yourself several times on that
point. I'm no longer sure quite -what- you're claiming will happen.
But, as I've said before, and as others have said on this thread, it's
essential for a server-side process to cope with -any- input that gets
thrown as it. There's no way - repeat: NO way - that anything in your
HTML or js can protect the server against defective or plain malicious
inputs, and if the server-side process then does something harmful,
that's your fault (as developer of the procedure) for letting it.
So, js verification of the data can be a useful optional -extra- (to
avoid wasteful submission/rejection cycles), but must NEVER be
considered as an alternative to server-side validation of the input.
The client does not want this.
What the client wants, and what the WWW will do, are not necessarily
the same thing. It's our job as developers to resolve such
inconsistences ;-}
Just because JS is disabled, doesn't mean the form submit button
won't work.
I'm convinced that you also said the opposite. But no matter: your
server-side script can get invoked by anyone with a mind to do it, no
matter how hard you try to stop it in your HTML.
And I'd have to agree with those who pointed out the implications of
the WAI requirements if this is, for example, government work.
good luck with the project
Alan J. Flavell wrote: On Sat, 1 May 2004, SamMan wrote:
The client does not want this.
What the client wants, and what the WWW will do, are not necessarily
the same thing. It's our job as developers to resolve such
inconsistences ;-}
That's another of those nuggets that belongs in a faq or something. Well
said!
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
SamMan wrote: A sightless person has tested the forms and was able to fill out & submit
them.
*One* person trying the site with *one* browser doesn't mean everyone
will have the same experience. Did this person use an assistive
technology, as required by Section 508? Did they accomplish it without
JS and without the direction of someone else?
(BTW, I never wished to turn this into a flame thing, so I'll try to
keep out the maliciousness as much as possible.)
--
Michael Wilcox, http://mikewilcox.t35.com/
Michael Wilcox <mj************@yahoo.com> wrote: SamMan wrote:
The client would like to ensure the data remains, as
they sometimes have multiple submissions to make with similar entries.
This is a feature implemented in many browsers, but not all.
I hate to say it, but this is a case where pop-up windows may be
necessary--unless someone can come up with another way to handle a
form complicated enough to justify inclusion of Help links. If a user
has partially completed a form when he clicks a Help link, then after
the Help page has loaded in his browser, and he has hit the Back
button to return to his form, I guarantee that he will be annoyed if
his previous entries have all disappeared.
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Harlan Messinger wrote: I hate to say it, but this is a case where pop-up windows may be
necessary
Well, if PHP is available, popups are hardly necessary. I wish I could
think of a good solution when PHP isn't available, but a well designed
site should have to rely on potentially missing features.
unless someone can come up with another way to handle a
form complicated enough to justify inclusion of Help links.
I don't think the form in question is complicated (although I haven't
seen it), but I think the question is whether or not you could submit it.
--
Michael Wilcox, http://mikewilcox.t35.com/
SamMan wrote: A sightless person has tested the forms and was able to fill out & submit
them.
I forgot to add: Since a user with an assistive technology might fill in
the entire form, then find out he/she can't even submit it, why put put
a warning in noscript tags that this user won't be able to submit the
data. (Mean rant: Why would you do this? Why can't you just let a few
bad forms go through? Most people will probably fill them in regardless
of what browser they are using.)
--
Michael Wilcox, http://mikewilcox.t35.com/
Michael Wilcox <mj************@yahoo.com> wrote: Harlan Messinger wrote:
I hate to say it, but this is a case where pop-up windows may be
necessary
Well, if PHP is available, popups are hardly necessary. I wish I could
think of a good solution when PHP isn't available, but a well designed
site should have to rely on potentially missing features.
How does PHP alter the situation? Once a page is in a browser, the
browser doesn't know or care that the content was generated by PHP,
and the server has no awareness of or control over what the browser
does to the user's entries when the user returns to the form using the
Back button.
Actually, I have a feeling that I wasn't clear. When I said "this is a
case where pop-up windows may be necessary", by "this" I didn't mean
"the OP's problem". I meant "pages with forms on them that also
contain links people are likely to click while they are completing the
form". I was referring to another issue that has been raised here many
times: pop-up windows, which some people are opposed to altogether. So
I'm saying, *this* (forms with Help links, for example) is a case
where pop-up windows may be indispensable.
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c7************@ID-230276.news.uni-berlin.de...
I don't think the form in question is complicated (although I haven't
seen it), but I think the question is whether or not you could submit it.
--
Actually, the question was... "Is there a way to ensure the values in the
fields remain on return (when the back button is clicked), or is this just a
quirk in browsers?"
The question was answered, by you Michael... and it kind of got off topic
after that. Some good discussion for a while, and some good points were
made. I wish I could have made the form like I wanted, using back-end
processing. Maybe then the post may not have even been needed.
I will raise the question of the form really meeting 508 (a really good
point that slipped by me), but I have a feeling I will be shot down.
Remember, this form and the others are not mine to maintain, so I have to
keep them to a simple level... trust me, they need to be very simple for
this person.
I have one more reply to answer to, and then this will be it for me. Thank
all of you for your valuable input.
--
SamMan
Rip it to reply
"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c7************@ID-230276.news.uni-berlin.de... SamMan wrote:
A sightless person has tested the forms and was able to fill out &
submit them.
I forgot to add: Since a user with an assistive technology might fill in
the entire form, then find out he/she can't even submit it, why put put
a warning in noscript tags that this user won't be able to submit the
data. (Mean rant: Why would you do this? Why can't you just let a few
bad forms go through? Most people will probably fill them in regardless
of what browser they are using.)
Where did you get the idea there was a warning in the noscript tag? There is
none, and I said no such thing. I said there was a disabled submit button
contained therein. There is a text warning at the top of the page, that
displays regardless.
Again, if it were up to me, I would let a few bad forms get through. In fact
another team member (not the "veteran") and I had that exact discussion and
both of us were in agreement. The bad part is, the Gov's office is used to
getting what they want, and if not, they raise a big fuss over it... due in
part to how the person in official charge of the site (the "veteran") has
handled things in the last 8 years. They were only getting about one to two
a month that would come in blank, but that wasn't good enough for them...
sigh...
Thank you one more time for your help.
--
SamMan
Rip it to reply
On Sat, 01 May 2004 19:12:08 -0400, Harlan Messinger
<hm*******************@comcast.net> wrote: When I said "this is a
case where pop-up windows may be necessary", by "this" I didn't mean
"the OP's problem". I meant "pages with forms on them that also
contain links people are likely to click while they are completing the
form". I was referring to another issue that has been raised here many
times: pop-up windows, which some people are opposed to altogether. So
I'm saying, *this* (forms with Help links, for example) is a case
where pop-up windows may be indispensable.
Judicious use of the title attribute could perhaps solve the problem you
describe. Really, if the user filling out the form needs a whole web page
to describe how to do it, perhaps that should be worked in a little better
than a link in the form.
On Fri, 30 Apr 2004, SamMan wrote: "Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk... On Fri, 30 Apr 2004, Michael Wilcox wrote:
This is a feature implemented in many browsers, but not all. You cannot
rely on it, since you cannot manipulate the user's browser.
right...
However, if a problem is encountered and an error is found by
checking it with PHP, you should be able to reconstruct the form and
fill in the values, all using PHP. The user shouldn't have to depend
on a feature his/her browser might not have.
Good answer. The same is true for other server-side scripting, though
- it's not limited to PHP: for example the CGI.pm module makes this
quite straightforward in Perl with CGI.
> There is client-side validation (JavaScript) on the forms, but other than > that, nothing else special about them.
JS validation is ok, but most defiantly should not be relied on.
Oh, most "defiantly" true ;-) SCNR.
js checks can be useful to both parties as an optional convenience,
but most certainly the submitted parameters must be fully[1] validated
at the server.
[1] where "fully" is defined by the requirements of the application.
hth
Thanks to both of you for your advice. I kind of thought it was a browser
specific feature.
I agree that JavaScript (JS) isn't generally the best tool, but in this
case, I think it works. The form(s) just takes the form data and sends it to
an e-mail account(s), and is never processed any further (database, etc.).
The JS just basically checks for null values and formatting, so when the
data is sent to the person in charge of the ceremonies, it is clear & makes
sense to them. I also have it so if the end-user has JS disabled, the submit
button is also disabled. I wrote the backend to replace a Pearl script that
our agency was not allowed to alter (working for state agencies is fun!),
and made it hard to manage & alter. Also, the person really in charge of the
forms (and site) is a "veteran" of 10 years in web dev that can't even write
simple JS. I wanted to do all of the validation server-side, but couldn't,
as I had to keep it as simple as possible for the co-worker.
You disable the submit button if javascript isn't available? That by itself is
going to turn alot of the SMARTER users away - those who universally disable JS
without further thought due to its security flaws. You may be lucky in that it
usually defaults on and many people don't even know how to turn it off.
A "GOOD" web page doesn't depend on ANY feature of a client's program to provide
its minimal functionality. Javascript should only be used to ENHANCE a page -
not be the difference between functional and not.
Please post your domains so we can all avoid your brain-dead sites.
On Fri, 30 Apr 2004, Michael Wilcox wrote: Alan J. Flavell wrote: Oh, most "defiantly" true ;-) SCNR.
Damn you convenient spell checker! *sigh* It's my own fault, but whatever...
Are you certain that's a spelling mistake? I get the hidden meaning.....
On Sat, 1 May 2004, SamMan wrote: "Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote: I also have it so if the end-user has JS disabled, the submit
button is also disabled.
What good is that? How would I ever submit my form if my JS is off? Or
if I don't even have it?
Because, like I said... the JS is only used to check for null values and/or
formatting of the fields. If JS is disabled, the form can be submitted with
all blank fields. The client does not want this. Just because JS is
disabled, doesn't mean the form submit button won't work.
How is he going to submit it if your <script> operation removes the submit
button from being formed in the first place (that certainly disables the
button) or the <input type=submit disabled ...> is present (assuming the client
program honors the latter)?
On Sat, 1 May 2004, SamMan wrote: "Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote:
Just because JS is disabled, doesn't mean the form submit button won't
work.
I'll answer that with a quote from you: "I also have it so if the
end-user has JS disabled, the submit button is also disabled."
Does this mean that if I have my JS off, I can't submit your form?
--
Yes... and only because I have coded it so. Without the code I wrote, if the
user has JS disabled, the submit button still functions.
But that's not how you coded it, per your own statement. Obviously, if you're
not a troll, you're an idiot; either way, go away.
On Sat, 1 May 2004, SamMan wrote: "Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de... SamMan wrote: Yes... and only because I have coded it so. Without the code I wrote, if the user has JS disabled, the submit button still functions.
That's a poor choice. The user's browser may not have JS, or it may be
turned without the intention of turning it on again. Some people turn it
off for good reason, and it's a pain to turn it back on just to do
something like this. Like I said before, it's really better to do the
regex stuff with PHP.
Can I ask how you accomplish preventing the browser from submitting?
--
I agree that it would be better to do all error checking on the server, but
like I have stated before, I have to accommodate the developer who has
little to no experience in JS, let alone anything that happens on the server
side. They are the one who has "official" control over the site, and as
such, things must be done to make it easier for them... one of the pitfalls
of working for a government agency.
I do have to disagree with you on your point that it is a pain to turn on,
or enable JS. I generally use IE, and can disable/enable JS in a matter of
seconds.
How I accomplish the disabled button is I have a JS function that returns a
functional button. If JS is disabled, I have a disabled button wrapped
inside noscript tags.
In which case, it's disabled and doesn't work even if it's displayed on the
screen, so how can the user still submit (with all field data blank) as you said
that he could a few posts ago?
On Fri, 30 Apr 2004, Sherm Pendley wrote: SamMan wrote: How I accomplish the disabled button is I have a JS function that returns
a functional button. If JS is disabled, I have a disabled button wrapped
inside noscript tags.
What happens when a user hits return? A button isn't the only way to submit
a form...
That usually only works when there is a SINGLE text-type input field.
Otherwise, you will find that many browsers don't submit upon a carriage return.
On Sat, 1 May 2004, Alan J. Flavell wrote: On Sat, 1 May 2004, SamMan wrote: If JS is disabled, the form can be submitted with all blank fields. ...
So, js verification of the data can be a useful optional -extra- (to
avoid wasteful submission/rejection cycles), but must NEVER be
considered as an alternative to server-side validation of the input.
A point that all too many AMATEUR web designers often fault on. Just because
you're paid doesn't make you a professional in this case. Professionals have
training that makes them see these TRIVIAL matters and avoid them.
The client does not want this.
What the client wants, and what the WWW will do, are not necessarily
the same thing. It's our job as developers to resolve such
inconsistences ;-}
Just because JS is disabled, doesn't mean the form submit button
won't work.
I'm convinced that you also said the opposite. But no matter: your
server-side script can get invoked by anyone with a mind to do it, no
matter how hard you try to stop it in your HTML.
He said something different but not necessarily opposite. He could have his
submit button code between <script> tags and not offer it in the <noscript>
alternative, or offer one with a "disabled" control in the <input> tag.
However, he was clear: If JS is disabled, so is his submit button.
And I'd have to agree with those who pointed out the implications of
the WAI requirements if this is, for example, government work.
"SamMan" <sa*@psfdevrip-it.com> wrote in
news:EB****************@twister.rdc-kc.rr.com: A sightless person has tested the forms and was able to fill out &
submit them.
The proper term is "blind." Every single advocacy organization run by
blind people uses that word in their group's name. It's how blind people
refer to themselves. It's only one syllable. It's been in use for
centuries.
Euphemisms like "sightless" convey the impression that someone is concerned
about not offending members of some group, but doesn't know very much about
said group, certainly not enough to know what they might or might not find
offensive. The actual effect is to make one sound, not sensitive, but
patronizing.
Oh, and avoid "visually impaired"; it's too imprecise. In an
accessibility/usability context, what will work for someone who cannot use
their vision, no matter how augmented, to use a site/product/technology and
what will work for someone who uses their vision with heavy augmentation
are often quite different (though in many cases, the correct solution is
simply to get out of the user's way and not try to second-guess him).
On Sun, 02 May 2004 06:48:38 GMT, "D. Stussy" <kd****@bde-arc.ampr.org>
wrote: On Fri, 30 Apr 2004, Sherm Pendley wrote:
What happens when a user hits return? A button isn't the only way to submit
a form...
That usually only works when there is a SINGLE text-type input field.
Otherwise, you will find that many browsers don't submit upon a carriage return.
Just to clarify: pressing Return (whether focus is in a single-line text
input field or not) does not, in itself, submit a form. Submit buttons
function as "default button", which means that they, in some
circumstances, react to the Enter key being pressed even if focus is
somewhere else. If the submit button is disabled, as the OP indicated,
this will of course have no effect.
Gertjan.
--
Gertjan Klein <gk****@xs4all.nl>
On Sun, 2 May 2004, Gertjan Klein wrote: Just to clarify: pressing Return (whether focus is in a single-line text
input field or not) does not, in itself, submit a form.
That doesn't clarify anything - as a general statement, it's just
plain wrong.
Submit buttons function as "default button",
Sorry, I don't understand what you're trying to say. Maybe you're
describing the user interface conventions in one particular browser
implementation, but I'm sure that this is not a property of the WWW
specifications in themselves.
In the terms of the HTML2.0 specification (RFC1866), http://www.w3.org/MarkUp/html-spec/h..._8.html#SEC8.2 (second
paragraph), it's not even essential for such a form to *have* any
submit button (I'm not actually recommending that, but it would at
least be logically consistent).
And many browsers still behave in conformance with that part of the
original spec, whatever they might do in other situations.
hth.
Neal <ne*****@yahoo.com> wrote: On Sat, 01 May 2004 19:12:08 -0400, Harlan Messinger
<hm*******************@comcast.net> wrote:
When I said "this is a
case where pop-up windows may be necessary", by "this" I didn't mean
"the OP's problem". I meant "pages with forms on them that also
contain links people are likely to click while they are completing the
form". I was referring to another issue that has been raised here many
times: pop-up windows, which some people are opposed to altogether. So
I'm saying, *this* (forms with Help links, for example) is a case
where pop-up windows may be indispensable.
Judicious use of the title attribute could perhaps solve the problem you
describe. Really, if the user filling out the form needs a whole web page
to describe how to do it, perhaps that should be worked in a little better
than a link in the form.
No matter how you do it, there are really only two choices: either
have all of the how-to on the same page as the form, or have it on a
separate page. If it's on a separate page, then the user is going to
want to go back and forth between the form and the instructions, and
that can cause the problem that has been described. In bringing this
up at all, I was presupposing there was a reason why the instructions
might be too lengthy to include on the page with the form; or the Help
page might be a site-wide help that needs to be accessible from every
page on the site, or from *every* form on a site that has a large
number of forms. Of course, using SSI, the same instructions could
just be included *on* every page with a form.
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
On Sun, 02 May 2004 06:57:42 GMT, "D. Stussy"
<kd****@bde-arc.ampr.org> wrote: I'm convinced that you also said the opposite. But no matter: your
server-side script can get invoked by anyone with a mind to do it, no
matter how hard you try to stop it in your HTML.
He said something different but not necessarily opposite. He could have his
submit button code between <script> tags and not offer it in the <noscript>
alternative, or offer one with a "disabled" control in the <input> tag.
However, he was clear: If JS is disabled, so is his submit button.
JS available is not a black and white thing, you can have script
enabled but no onsubmit/onclick event for example.
If you use NOSCRIPT in your pages, you're not taking enough care with
your script. NOSCRIPT should not be used.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
On Sun, 2 May 2004, Jim Ley wrote: If you use NOSCRIPT in your pages, you're not taking enough care with
your script. NOSCRIPT should not be used.
Sounds like a topic that calls for being covered in your FAQ, no?
On Sun, 2 May 2004 15:08:30 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote: On Sun, 2 May 2004, Jim Ley wrote:
If you use NOSCRIPT in your pages, you're not taking enough care with
your script. NOSCRIPT should not be used.
Sounds like a topic that calls for being covered in your FAQ, no?
I no longer edit it, I'll try and encourage the current editor in that
direction though.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Eric Bohlman wrote: In an accessibility/usability context, what will work for someone who
cannot use their vision, no matter how augmented, to use a
site/product/technology and what will work for someone who uses their
vision with heavy augmentation are often quite different (though in
many cases, the correct solution is simply to get out of the user's
way and not try to second-guess him).
That is the easiest and most efficient thing to do. Pity so many don't
take that advice.
--
Brian (remove "invalid" from my address to email me) http://www.tsmchughs.com/
Eric Bohlman <eb******@earthlink.net> wrote: Oh, and avoid "visually impaired"; it's too imprecise. In an
accessibility/usability context, what will work for someone who cannot use
their vision, no matter how augmented, to use a site/product/technology and
what will work for someone who uses their vision with heavy augmentation
are often quite different
Yep. And often, what works for two individuals with basically the same
degree of vision loss will be quite different.
(though in many cases, the correct solution is
simply to get out of the user's way and not try to second-guess him).
Amen.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"You learn nothing new the third time a mule kicks you in the head." This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Vanessa |
last post by:
Hi all !
I am looking for a php class and page layout framework allowing smooth
object oriented insertion of several, possibly different, forms within
the same page layout.
All of that while...
|
by: noor |
last post by:
Hi
I have been working since 2 days to device a method to export sql table
into csv format. I have tried using bcp with format option to keep the
column names but I'm unable to transfer the file...
|
by: JW |
last post by:
Dear NG,
Still working on my .NET CF C# forms application ...
I have an array of forms that I wish to display in array order, and thus
have created a loop to run through them. Due to...
|
by: 23s |
last post by:
I had this problem in the past, after a server reformat it went away, and
now after another server reformat it's back again - no clue what's doing it.
Here's the flow:
Website root is public, no...
|
by: Rob |
last post by:
I am doing something wrong in declaring variables for
forms I want to load. When the declaration is read, the
form closes. I have a form, Form1, that loads at
startup. After the...
|
by: jung_h_park |
last post by:
From: jung_h_park@yahoo.com
Newsgroups: microsoft.public.dotnet.framework.aspnet
Subject: Dropdown List not retaining its SelectedValue
Date: Mon, 26 Jun 2006 21:02:57 -0700
Hello,
My...
|
by: David Cartwright |
last post by:
Hi all,
I'm using a DataGrid to present a tabulated list (actually a list of users
logged in to my phone system) - it seemed the most appropriate control. As
stuff happens on the phone system,...
|
by: RoMo |
last post by:
I am using VB .NET (2003) for a project that includes a datagrid on one form that allows the user to switch to details on a second form. The datagrid was built in design mode with all the proper...
|
by: s4lin |
last post by:
problem is pagination not retaining data field
i have form with general data field, and i need to select some option which is store in database, so i open another page with retrieving data from...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
