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

[D. Stussy]

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.

[Eric Bohlman]

"SamMan" <sa*@psfdevri p-it.com> wrote in
news:EB******** ********@twiste r.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).

[Gertjan Klein]

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>

[Alan J. Flavell]

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.

[Harlan Messinger]

Neal <ne*****@yahoo. com> wrote:

On Sat, 01 May 2004 19:12:08 -0400, Harlan Messinger
<hm*********** ********@comcas t.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.

[Jim Ley]

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.javas cript FAQ - http://jibbering.com/faq/

[Alan J. Flavell]

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?

[Jim Ley]

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.javas cript FAQ - http://jibbering.com/faq/

[Brian]

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/

[Darin McGrew]

Eric Bohlman <eb******@earth link.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****@stanford alumni.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."