Forms Retaining Data

[SamMan]

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

[Daniel R. Tobias]

"SamMan" <sa*@psfdevrip-it.com> wrote in message news:<P2**************@twister.rdc-kc.rr.com>...

"Michael Wilcox" <mj************@yahoo.com> wrote in message
news:c6************@ID-230276.news.uni-berlin.de...

SamMan wrote:
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.

People who purposely make forms fail to function with JavaScript
disabled, which would otherwise be pefectly usable, deserve to be
taken to the village square and publicly whipped.

--
Dan
Dan's Web Tips: http://webtips.dan.info/

[Gertjan Klein]

On Sun, 2 May 2004 13:16:11 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

On Sun, 2 May 2004, Gertjan Klein wrote:

Submit buttons function as "default button",
Sorry, I don't understand what you're trying to say.

I was trying to say that pressing the Enter key activates the submit
button, even if it doesn't have focus. This is different from the Enter
key submitting the form directly.

The reason for my remark was to indicate why the form would *not* submit
if the submit button was disabled.
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.
I don't know if it's formally specified anywhere, but it works like that
in more than one browser. I found the HTML 4.01 spec rather vague about
*how* a submit button is "activated".
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).

True, and I was unaware of this. However, the paragraph you refer to
starts with: "When there is only one single-line text input field in a
form". I must admit that I find this a bit ambiguous. Does this mean to
describe the situation where a form contains only a single-line text
input, or can it contain other inputs (but no other single-line text
inputs)?

At least on Mozilla 1.6, Opera 7.23, and IE 6, *if* a submit button is
present, besides one single-line text input, disabling the submit button
disables the described functionality - i.e., pressing Enter no longer
submits the form. This suggests to me that at least their interpretation
is consistent with what I wrote.

But you are right, I described behaviour of specific implementations,
and e.g. Konqueror 3.1.3 *does* submit the form described in the
previous paragraph.

Gertjan.

--
Gertjan Klein <gk****@xs4all.nl>

[Spartanicus]

"D. Stussy" <kd****@bde-arc.ampr.org> wrote:

Please trim your quoting to the bare minimum.

--
Spartanicus

[Kris]

In article <aa**************************@posting.google.com >,
da*@tobias.name (Daniel R. Tobias) wrote:

People who purposely make forms fail to function with JavaScript
disabled, which would otherwise be pefectly usable, deserve to be
taken to the village square and publicly whipped.

Or thrown from the castle's bridge.

--
Kris
<kr*******@xs4all.netherlands> (nl)
<http://www.cinnamon.nl/>

[Brian]

Jim Ley wrote:

On Sun, 02 May 2004, "D. Stussy" wrote:

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.

Being a novice in js, I'm afraid I don't quite grasp this. On a general
level, it seems plausible, but could you explain have a js enabled
browser but no onsubmit event? Surely you mean on the client end?
If you use NOSCRIPT in your pages, you're not taking enough care with
your script. NOSCRIPT should not be used.

In this particular case? Or are you saying that NOSCRIPT should never be
used?

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Eric Bustad]

Jim Ley wrote:

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.

What about those using browers that either don't support javascript or
have it disabled?

= Eric

[Alan J. Flavell]

On Mon, 3 May 2004, Gertjan Klein wrote:

The reason for my remark was to indicate why the form would *not* submit
if the submit button was disabled.
Interesting, thanks. Yes, I can see evidence of the behaviour that
you're describing, in various browsers. I must admit this was not an
area that I had specifically explored before.
I don't know if it's formally specified anywhere, but it works like that
in more than one browser. I found the HTML 4.01 spec rather vague about
*how* a submit button is "activated".
Indeed, and there have been a number of arguments about whether
_any_ "submit" control can be counted as a "successful control"
(in the terms of
http://www.w3.org/TR/html401/interac...ssful-controls )
when the form is submitted without using any of them (e.g by hitting
Enter).

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).

True, and I was unaware of this. However, the paragraph you refer to
starts with: "When there is only one single-line text input field in a
form". I must admit that I find this a bit ambiguous. Does this mean to
describe the situation where a form contains only a single-line text
input, or can it contain other inputs (but no other single-line text
inputs)?

Here's an answer to that question which I prepared earlier ;-)
http://ppewww.ph.gla.ac.uk/~flavell/...mquestion.html
At least on Mozilla 1.6, Opera 7.23, and IE 6, *if* a submit button is
present, besides one single-line text input, disabling the submit button
disables the described functionality - i.e., pressing Enter no longer
submits the form. This suggests to me that at least their interpretation
is consistent with what I wrote.

OK, thanks for responding to this point. I've learned something. As
it says, I deliberately excluded discussion of scripting from that
page of mine; and DISABLED is an attribute which only makes any kind
of practical sense when scripting is in use. So I hadn't explored
those issues before.

All the best

[Harlan Messinger]

"Jim Ley" <ji*@jibbering.com> wrote in message
news:40***************@news.individual.net...

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 hissubmit 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.

What does the care you take with your script have to do with the
advisability of providing an alternative for people who aren't executing
your script?

[Jim Ley]

On Mon, 03 May 2004 21:16:54 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

Jim Ley wrote:

On Sun, 02 May 2004, "D. Stussy" wrote:

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.

Being a novice in js, I'm afraid I don't quite grasp this. On a general
level, it seems plausible, but could you explain have a js enabled
browser but no onsubmit event? Surely you mean on the client end?

of course on the client, but onsubmit is an event, there almost
certainly some javascript capable UAs that have no onsubmit event,
although that's probably very rare, what I certainly use often is a
script which submits a form without firing onsubmit, because
client-side scripts are so bad. The larger problem though is in what
happens when there's an error in your validation code, this is very
common - using RegExp's in a non-RegExp capable client for example.
So you always need to protect against what happens when any part of
your script isn't available or errors or whatever.

If you use NOSCRIPT in your pages, you're not taking enough care with
your script. NOSCRIPT should not be used.

In this particular case? Or are you saying that NOSCRIPT should never be
used?

I've never seen a case! Your script will error in a browser, or it
won't do what you expect, there's no escaping this fact, and in those
circumstances you need to ensure that your page still works - if your
"no javascript" fallback is hidden from the user inside a NOSCRIPT it
won't help on jot. What you need to do is have the javascript only
ADD functionality to a page, so you should never need a NOSCRIPT to be
the functional equivalent of a piece of script, just leave the basic
page there.

So for example, instead of:

<script type="text/ecmascript">
document.write("something with snazzy features");
</script>
<noscript>
something
</noscript>

do

something
<script type="text/ecmascript">
if (variousObjectTests() ) {
// Use some script to add to something, or replace
// something or whatever is appropriate
}
</script>

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Jim Ley]

On Tue, 4 May 2004 10:30:34 -0400, "Harlan Messinger"
<h.*********@comcast.net> wrote:

If you use NOSCRIPT in your pages, you're not taking enough care with
your script. NOSCRIPT should not be used.

What does the care you take with your script have to do with the
advisability of providing an alternative for people who aren't executing
your script?

Because you cannot take sufficient care, therefore don't bother,
redesign your script so that it only adds functionality so there is no
equivalent needed.

You will not be able to take enough care, any real world script you
show me, I'll give you a way it can fail, with most I'll probably be
able to find a UA where it actually fails, rather than just a
theoretical. Scripts fail, you can't do anything about it, it's all
about controlling the ways they fail :-)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Brian]

Jim Ley wrote:

onsubmit is an event, there almost certainly some javascript capable
UAs that have no onsubmit event, although that's probably very rare
So if there's no onSubmit event, then a script attached to that event
will never fire. But relying on js for form submission seems crazy
anyways. I tried S. Poley's idea of quick client-side data validation
tied to onChange and onSubmit; the script returns false if something is
wrong. But I don't see any danger in this approach, so long as
validation is also done server-side as necessary.
what I certainly use often is a script which submits a form without
firing onsubmit,
How do you do that?
because client-side scripts are so bad.
Processing scripts?
The larger problem though is in what happens when there's an error in
your validation code, this is very common - using RegExp's in a
non-RegExp capable client for example.
Hmm. The validation script does use RegExp. So what happens with a
script that validates using RegExp in a client that has onSubmit and no
RegExp? I'd better think about that.

In this particular case? Or are you saying that NOSCRIPT should
never be used?

I've never seen a case!

banal example: using js write() to write a mailto: email address, and
NOSCRIPT to write that address as plain text.
you need to ensure that your page still works - if your "no
javascript" fallback is hidden from the user inside a NOSCRIPT it
won't help on jot.
That's good general advice.
for example, instead of:

<script type="text/ecmascript">
document.write("something with snazzy features");
</script>
<noscript>
something
</noscript>

do

something
<script type="text/ecmascript">
if (variousObjectTests() ) {
// Use some script to add to something, or replace
// something or whatever is appropriate
}
</script>

Good example. But you need, then, to add the "snazzy features" via js
without replacing it. If you replace it, something could still go wrong,
e.g., the client removes "something" but fails to put "something with
snazzy features" in its place.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Jim Ley]

On Sat, 08 May 2004 08:44:50 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

Jim Ley wrote:

In this particular case? Or are you saying that NOSCRIPT should
never be used?

I've never seen a case!

banal example: using js write() to write a mailto: email address, and
NOSCRIPT to write that address as plain text.

So you believe document.write exists so you can do that safely - those
people who don't have document.write (and document is in no standard
so can you really expect it to be?) don't get anything, the
appropriate way - if there was any point doing it would be to write it
plain text then use DOM methods to change it into a mailto.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Brian]

Jim Ley wrote:

Brian wrote:

banal example: using js write() to write a mailto: email address,
and NOSCRIPT to write that address as plain text.
So you believe document.write exists so you can do that safely -
those people who don't have document.write

Well, I *used* to believe that. ;-)
(and document is in no standard so can you really expect it to be?)
Did I mention that I'm not all that familiar with js? (No, that is not
an excuse. I should learn more about it before using it.)
the appropriate way - if there was any point doing it
There is much debate about munging addresses. I've reluctantly decided
to mung because the spam gets overwhelming, and because it annoys me
perhaps more than it should.
write it plain text then use DOM methods to change it into a mailto.

Thanks for suggestion. I didn't know that such a thing was even
possible. It might be a bit out of my league, but I can start learning
about DOM methods and changing nodes.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Bruce Lewis]

Gertjan Klein <gk****@xs4all.nl> writes:

At least on Mozilla 1.6, Opera 7.23, and IE 6, *if* a submit button is
present, besides one single-line text input, disabling the submit button
disables the described functionality - i.e., pressing Enter no longer
submits the form. This suggests to me that at least their interpretation
is consistent with what I wrote.

However, with just one single-line text input, they will not send any
value specified for a named submit button. Thus pressing Enter and
activating the submit button aren't exactly the same.

[Brian]

Bruce Lewis wrote:

with just one single-line text input, they will not send any
value specified for a named submit button. Thus pressing Enter and
activating the submit button aren't exactly the same.

Google does no appear to work that way. I type text in the only input of
their search form and press my <enter> key. The result is a get request
identical to one caused by pressing the "Google Search" button with a
mouse or the keyboard.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Richard Cornford]

Jim Ley wrote:

"Alan J. Flavell" wrote:
snip>

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.

You will encourage me more effectively with e-mail than relying on me to
have time to catch up with the HTML groups. :)

But consider me encouraged as I share your opinion and don't consider
NOSCRIPT tags at all useful. They just don't represent the correct
relationship to be applicable to the problem.

Richard.