Why Internet Explorer likes to clear forms

[webmistress]

Sorry if I have posted this in the wrong forum.

Just a question... Does anyone know why Internet Explorer v 6 clears forms if you have made an error and you need to use your back button . . . You know what I mean?
I have a job application form and when you use it with Firefox it's fine! I mean if you have missed a field out and you need to go back, it loads to page with all the data you entered (in FF)... but not with IE. . . .??

Is this fixable, or is it just a stupid IE trait.
Help.

Thanks.

Laura - Loving Firefox.

[Si]

I think it's just a caching issue. IE has virtually always done this to forms and it can be VERY annoying when you're completing long application forms.

I think when FireFox was being developed, they implemented the form thing as many people were annoyed by this.

Off Topic:


Whereabouts in Derbyshire are you from? I was born in Derby and I'm still a proud (for some reason) Rams fan. (PM if you want)

[webmistress]

Oh thanks for the reply!

Arr microw*** - you get me. hehe

I must admit I have not looked back with Firefox, I even took IE off my toolbar but obviously use it for testing purposes. Does anyone know if IE 7 is going to be out dsoon?

[stymiee]

IE7 is not going to be releases as a separate browser. You'll have to buy the new operating system in 2006/2007 when it ocmes out. Kinda sucky if you ask me.

[webmistress]

What that is terrible. Oh well, let hope Firefox takes over the market.

[stymiee]

What that is terrible. Oh well, let hope Firefox takes over the market.

YES!!!!!!!

[Sleeper]

I always thought they cleared the form to build up your hate of them, like evil at work.

[dotDan]

header("Cache-control: private"); 

Doesn't this PHP take care of that problem, or does it have a separate usage?

[redux]

I mean if you have missed a field out and you need to go back, it loads to page with all the data you entered (in FF)... but not with IE. . . .??

coming in late on this, but...this just proves a very significant point with regards to accessibility: don't rely on client side functionality. do as much as you can server side, as you never know what capabilities the client has. in this particular context: if the user missed out a field, provide them with a link to go back, or show the form fields right there at the receiving page, and pre-fill them with the data they have already submitted that was correct. yes, it's extra work on the development side, but it guarantees that your forms will be more resilient even if users have IE or any alternative browser.

[Thing]

coming in late on this, but...this just proves a very significant point with regards to accessibility: don't rely on client side functionality. do as much as you can server side, as you never know what capabilities the client has. in this particular context: if the user missed out a field, provide them with a link to go back, or show the form fields right there at the receiving page, and pre-fill them with the data they have already submitted that was correct. yes, it's extra work on the development side, but it guarantees that your forms will be more resilient even if users have IE or any alternative browser.

I've always believed that checking form fields via client-side is the way to go. Why send a request to the server when the data is incorrect? That way there should be no reason for the user to go back, because they can only go forward once they have it exactly right.

[redux]

I've always believed that checking form fields via client-side is the way to go. Why send a request to the server when the data is incorrect? That way there should be no reason for the user to go back, because they can only go forward once they have it exactly right.

except when the client side does not support javascript, or has javascript disabled.
(and don't start quoting stats from thecounter or similar crap, telling me that 99.7% of users have javascript enabled, as those stats are useless unless they directly relate to your particular site; the problem of disabled/non-existent javascript support is a real one)
nothing stops you from having client-side validation, but for accessibility reasons you can't rely on it, and should have validation and, in case of missing/wrong fields, a chance for the user to make changes implemented on the server-side as well.

[webmistress]

except when the client side does not support javascript, or has javascript disabled.
(and don't start quoting stats from thecounter or similar crap, telling me that 99.7% of users have javascript enabled, as those stats are useless unless they directly relate to your particular site; the problem of disabled/non-existent javascript support is a real one)
nothing stops you from having client-side validation, but for accessibility reasons you can't rely on it, and should have validation and, in case of missing/wrong fields, a chance for the user to make changes implemented on the server-side as well.

Do you know what percentage of people do have javascript disabled? It's one thing I never really thought of!

Thanks for all the input people.

[redux]

Do you know what percentage of people do have javascript disabled? It's one thing I never really thought of!
Thanks for all the input people.

it's irrelevant in terms of accessibility, and as i said any stats out there are irrelevant because what counts is the actual demographic for your particular site. running a large university site, i still have about 5-10% of users without javascript - particularly visitors accessing the site from colleges, high schools, etc where the IT department has imposed draconian "no scripts" settings. also researchers using older machines because they need to run specific software which does not run on newer operating systems (a few DOS based analysis programs etc), and have javascript disabled so it doesn't slow down their old machine. there are lots of valid scenarios in which javascript may not be present. an additional issue could well be javascript that only runs in a browser, but fails in another due to flaky implementation (e.g. IE only jscripts which break horribly on Mozilla).

in the light of all this, it's best practice not to rely on javascript or any other client side functionality. do as much as you can with the things you *can* control, i.e. the server-side. again, you can then proceed to add extra usability features like client-side validation etc which, in many cases, will save an extra roundtrip to the server, but at least you know that should that fail, there is a graceful degradation path / failsafe mechanism.

[webmistress]

Thanks for the advice.

[Thing]

except when the client side does not support javascript, or has javascript disabled.
(and don't start quoting stats from thecounter or similar crap, telling me that 99.7% of users have javascript enabled, as those stats are useless unless they directly relate to your particular site; the problem of disabled/non-existent javascript support is a real one)
nothing stops you from having client-side validation, but for accessibility reasons you can't rely on it, and should have validation and, in case of missing/wrong fields, a chance for the user to make changes implemented on the server-side as well.

I would agree with that. I usually handle form validation both client side and server side, that way I have all of my bases covered. Good points though!

[redux]

I usually handle form validation both client side and server side, that way I have all of my bases covered.

yup, that's the way

[boxhead]

yup, that's the way

HOW?!

I am in the process of creating a text only version of my site which uses a javascript to change the font size/colour. How do I get the code to run server side if scripts are turned off? How do I turn scripts off so i can test it works?

cheers

monkey

[redux]

How do I get the code to run server side

you can't run javascript server-side. you need PHP/ASP/JSP or similar.
you basically provide a fallback mechanism: something that works server-side if scripting is turned off, and after that you create javascript that can run client-side and - if present - can override any extra call to the server.

How do I turn scripts off so i can test it works?

assuming you're on IE: Tools -> Internet Options -> Security tab - > Custom Level. Set "Scripting / Active scripting" to "disabled"

[boxhead]

you can't run javascript server-side. you need PHP/ASP/JSP or similar.
you basically provide a fallback mechanism: something that works server-side if scripting is turned off, and after that you create javascript that can run client-side and - if present - can override any extra call to the server.



assuming you're on IE: Tools -> Internet Options -> Security tab - > Custom Level. Set "Scripting / Active scripting" to "disabled"

I thought that jscript in iis was used for server side javascript?

Any-how, does this mean that I don't have to worry about javascript fro accessable websites, ony ASP etc?

monkey

[redux]

I thought that jscript in iis was used for server side javascript?

don't confuse javascript in your page with jscript run server-side (as part of the .net suite of languages, presumable?)

Any-how, does this mean that I don't have to worry about javascript fro accessable websites, ony ASP etc?

no. you need to ensure that even if scripting is off, your site works in the same or comparable way. if you're only using javascript for purely visual fluff (rollovers etc) you should be fine (unless you use rollovers to provide extra information or similar). but if your site relies on javascript to function, then it cannot be classed as accessible. if javascript is not available client-side, your site would just stop working. you can't base your functionality on client-side capability.