Back-button problems on certain web sites

[nick4soup]

General advice wanted:

Some web sites (including two large companies in Australia) get
themselves awfully confused if the user presses the BACK button in
their browser (and possibly the forward button).

They are using ASP (or some other active script), but I presume it's
possible to make the same mistakes in CGI, or PHP, for instance.

Questions:
1. What is the usual cause of these difficulties - what is the
mistake(s) they have made?

2. How do I avoid the same traps when I start writing CGI (or ASP, at
gunpoint)? Are there some design principles I could follow?

I would like to allow the user a reasonable freedom to use the
back-button.
Nick Bishop
-----
I am different to most people in saying that I got sick of Hotmail -
without ever having an account there.
-oOo-

[Tim]

On 21 Feb 2005 19:32:33 -0800,
ni*******@yahoo .com.au posted:

Some web sites (including two large companies in Australia) get
themselves awfully confused if the user presses the BACK button in
their browser (and possibly the forward button).

They are using ASP (or some other active script), but I presume it's
possible to make the same mistakes in CGI, or PHP, for instance.

Questions:
1. What is the usual cause of these difficulties - what is the
mistake(s) they have made?
Using scripting to change pages, where the script only runs when the user
clicks something, but does nothing, or something unwelcome, while simply
traversing pages that you've already cached.
Meta refresh statements.
Not changing URIs when going between pages (e.g. playing damn fool tricks
with cookies to change pages but using the same URI).
Making perfectly cachable pages uncachable.
2. How do I avoid the same traps when I start writing CGI (or ASP, at
gunpoint)? Are there some design principles I could follow?

Read the specs for what you do use (HTML, CSS, even scripting), obey the
rules, and take heed of the cautions.
Don't use meta refresh/reload statements.
Avoid using any sort of redirects except for their proper purposes.
Use different URIs for all pages.
Don't make pages uncachable.
Don't rely or insist on client-side scripting.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

On Tue, 22 Feb 2005, Tim wrote:

Don't rely or insist on client-side scripting.

While trying to use it the other day, I noticed that this site:

http://www.nationalrail.co.uk/planmyjourney/

has some fairly heroic arrangements for dealing with users who don't
have javascript enabled. Unfortunately, it got itself totally
confused when I changed the browser's javascript setting after
accessing the initial enquiry page.

In a sense, they were trying to "not rely on or insist on" client-side
scripting, but they had made the wrong test for it.

[nick4soup]

Tim wrote:

On 21 Feb 2005 19:32:33 -0800,
ni*******@yahoo .com.au posted:

Some web sites (including two large companies in Australia) get
themselves awfully confused if the user presses the BACK button in
their browser (and possibly the forward button). 2. How do I avoid the same traps when I start writing CGI (or ASP, at gunpoint)? Are there some design principles I could follow?
Read the specs for what you do use (HTML, CSS, even scripting), obey

the rules, and take heed of the cautions.
OK, this is simpler than I thought. Any good material, FAQs or
validators for Javascript? (I know the rest)
Don't use meta refresh/reload statements.
Understood.
Avoid using any sort of redirects except for their proper purposes.
.... What purposes might they be??? Where should I read?
Use different URIs for all pages.
Don't make pages uncachable.
Understood.
Don't rely or insist on client-side scripting.

My only use of Javascript will be as a convenience:
- Moving the cursor to the first field the user has to type in a form
- Validations that save a round-trip to the server
- Enabling/disabling fields, based on (say) a checkbox.
None of this matters if the client's javascript is off, so long as you
ALWAYS, ALWAYS, ALWAYS duplicate client-side validations on the server.

Example of Enabling/disabling fields, based on a radio-button, in a
fictitious email application

(o) Move msg to new folder
Folder name [ ] <=== Enable this when
appropriate

( ) Move msg to existing folder [pulldown-list]

( ) Bounce message to sender (useful for spam)

They are using ASP (or some other active script), but I presume it's possible to make the same mistakes in CGI, or PHP, for instance.

I also get the idea in ASP etc to fetch out required session variables
to local variables, delete the entire session variable space, then load
the required variables back in, at the beginning of each ASP script.

Nick Bishop.
-----
Email replies ignored
-----
The truth hurts, but I have nerves of steel.
-oOo-

[Tim]

ni*******@yahoo .com.au posted:

Some web sites (including two large companies in Australia) get
themselves awfully confused if the user presses the BACK button in
their browser (and possibly the forward button).

2. How do I avoid the same traps when I start writing CGI (or
ASP, at gunpoint)? Are there some design principles I could follow?

Tim wrote:
Read the specs for what you do use (HTML, CSS, even scripting), obey
the rules, and take heed of the cautions.
ni*******@yahoo .com.au posted:

OK, this is simpler than I thought. Any good material, FAQs or
validators for Javascript? (I know the rest)
There is no standard Javascript. Netscape invented it and wrote the most
horrible documentation for it (hard to find, hard to read, poorly explained
and poorly authored), and just about all the browsers implement it
differently. It's no wonder that JavaScript is such a complete mess.

On the other hand, there's an attempt to standardise it with ECMA script.

<http://www.ecma-international.o rg/publications/standards/Ecma-262.htm>
<http://www.ecma-international.o rg/publications/standards/Ecma-290.htm>
<http://www.ecma-international.o rg/publications/standards/Ecma-327.htm>
<http://www.ecma-international.o rg/publications/standards/Ecma-357.htm>

Have a look at the <http://www.htmlhelp.or g/> website and see what they
offer about JavaScript. I don't use it (JavaScript), and have never
bothered to get into it, because of all the problems that are not going to
get resolved in the next several years, let alone getting something to work
nicely right now.

I hope by "know the rest" you actually mean that (know where the real specs
are, and understand them), rather than learnt from something that taught
you how to do it all wrong without you realising it.
Avoid using any sort of redirects except for their proper purposes. ... What purposes might they be??? Where should I read?
You could try looking up RFC +HTTP +redirect...

But basically, use redirects when you've had to relocate something (to fix
up problems). Don't go filling a website with redirects because you think
it's a cool way to organise the structure. Don't go reloading pages on
people as they're reading them, etc.
Don't rely or insist on client-side scripting.

My only use of Javascript will be as a convenience:
- Moving the cursor to the first field the user has to type in a form
I've only ever seen poorly designed pages get that wrong. All you have to
do is have your input elements actually written in the right logical order
in the HTML (however they're actually rendered).

Umm, this:
( ) Bounce message to sender (useful for spam)

Is not "useful". What it does is spam yet another person. I've *never*
seen a spam with a real "from" address, they've *always* forged one.
Usually some other spam victim's address.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Jim Ley]

On Mon, 28 Feb 2005 22:29:55 +1030, Tim <ti*@mail.local host.invalid>
wrote:

and just about all the browsers implement it
differently. It's no wonder that JavaScript is such a complete mess.
There's virtually no major differences with any browsers javascript
implementations , the few incompatibiliti es exist in very early
Netscape 4's where using the language="JavaS cript1.2" attribute can
cause problems.
Have a look at the <http://www.htmlhelp.or g/> website and see what they
offer about JavaScript. I don't use it (JavaScript),

Then maybe you would not be the best person to know incompatibiliti es
between it. There's very few differences between any current browser
( ([,]).length is one, but how often do people do that? ) and they are
extremely conformant to the standard.

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

[Dr John Stockton]

JRS: In article <11************ **********@f14g 2000cwb.googleg roups.com>
, dated Mon, 28 Feb 2005 02:19:19, seen in news:comp.infos ystems.www.aut
horing.html, ni*******@yahoo .com.au posted :

OK, this is simpler than I thought. Any good material, FAQs or
validators for Javascript? (I know the rest)

For that, you need a javascript newsgroup.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Tim]

Tim <ti*@mail.local host.invalid> wrote:

and just about all the browsers implement it
differently. It's no wonder that JavaScript is such a complete mess.

ji*@jibbering.c om (Jim Ley) posted:
There's virtually no major differences with any browsers javascript
implementations , the few incompatibiliti es exist in very early
Netscape 4's where using the language="JavaS cript1.2" attribute can
cause problems.

Ah right... that's why JavaScript tricks on webpages tend to only work on
the browsers that the author checked it with, because there's no major
differences between any of them.... (Heavy sarcasm)

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

On Tue, 1 Mar 2005, Tim wrote:

Ah right... that's why JavaScript tricks on webpages tend to only work on
the browsers that the author checked it with, because there's no major
differences between any of them.... (Heavy sarcasm)

I think you'll need to distinguish carefully between javascript the
programming language, and the browser's document object model.

[nick4soup]

Tim wrote:

Use different URIs for all pages.

Question.

I could read that two different ways.
1. Have a different URI for error pages,
2. Follow the rule "Don't use redirects except for their proper
purposes"

Elaboration:
If I have the user fill out a form, whose ACTION="theResp onse.php", and
the script theResponse.php encounters an error, is it best to send a
Redirect to an error page, or simply send out the error page under
theResponse.php URI?

Example of an error page:

ERROR0: The FBI has closed your account without warning.

or (sadly) more likely:

ERROR1: Your credit card was refused

ERROR2: Database error while trying to do a whooppie

ERROR3: You do not have enough money in your account for this

Thoughts?

Nick.
-----
Email responses ignored.
-oOo-