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*@psfdevri p-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
specificatio ns 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*******@xs4a ll.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.in dividual.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*****@juliet remblay.com.inv alid> 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 (variousObjectT ests() ) {
// Use some script to add to something, or replace
// something or whatever is appropriate
}
</script>

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

[Jim Ley]

On Tue, 4 May 2004 10:30:34 -0400, "Harlan Messinger"
<h.*********@co mcast.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.javas cript FAQ - http://jibbering.com/faq/