keep form elements enabled on "back" request

**Thomas 'PointedEars' Lahn** · Jul 23 '05, 09:00 PM

Re: keep form elements enabled on "back&quot ; request

Dani wrote:
[color=blue]
> I have some code that disables form elements on body load, but I notice
> when I hit the "back" button, I need to re-enable the form elements
> (that is done by clicking on a radial button). Is there any way I can
> keep the form for disabling every time a user hits the back button and
> "remember" what elements should be enabled?[/color]

No.
[color=blue]
> I was thinking maybe utilizing some referrer thing,[/color]

While the proprietary document.referr er property is seldom of use, it is
certainly not of use here. There is no "back" request as you imply with
the subject. The reknowned Back (button) feature is AFAIS implemented
either accessing the UA's cache or re-sending a GET request to the
previous URI stored in the "window"'s history. This means

1. the document.referr er property, if supported and if it contains a usable
value (which depends on the user agent, of course), will not contain the
"next" URI but the URI of the resource displayed before the form with the
disabled controls, if there was any.

2. because you do not have control over the user agent's cache usage,
you cannot assume any of the described behavior of a Back (button)
feature, if there is any. Especially, onload scripts are not executed
when using that feature and the document is accessed on the local cache.
[color=blue]
> but I'm not that good with JS yet.[/color]

This is not really a JS issue. Either don't disable the controls on load
(which would be best, considering that there are UAs without client-side
script support) or refer to the form in the previous (or rather, "next")
document using a visible _HTTP_ hyperlink. You then should use HTTP
techniques to have the resource requested from the server again instead
from the local cache with the latter approach:

<http://www.mnot.net/cache_docs/>
[color=blue]
> [...]
> <script language="JavaS cript">[/color]

From HTML 4 on, the `language' attribute is deprecated for valid reasons
while the `type' attribute is required for the same reasons. As the latter
has proven to be sufficient, the above should read

<script type="text/javascript">
[color=blue]
> function Disable_All()[/color]

Using identifiers starting with capital letters for script items that are
not used as constructors is discouraged by several JS code style guidelines
to avoid confusion and unexpected side effects, and to increase legibility
of source code.
[color=blue]
> {
> document.frmPos t.employeename. className="disa bled";[/color]
^
Blocks of source code should be properly indented using a reasonable number
of spaces, where multiples of 2 and/or 4 are recommended, especially when
it is posted to a public medium like this newsgroup.
[color=blue]
> document.frmPos t.employeename. disabled = true[/color]
^
While the automatic semicolon insertion feature of the language
allows to omit semicolons, it is highly recommended to include
them explicitely and consequently anyway to avoid "odd" script
behavior not easily understandable to beginners.
[color=blue]
> [...]
> for (var i = 0;i<8;i++){
> document.frmPos t.elements.hwre qested[i].disabled = true;
> }[/color]

1. DOM scripts should make use of standards compliant referencing whenever
possible, and always if that is also backwards compatible. The above
therefore should read

document.forms["frmPost"].elements["employeena me"].className="dis abled";
....
for (var i = 0;i<8;i++)
{
document.forms["frmPost"].elements["hwreqested "][i].disabled = true;
}

instead. Note that .disabled=true is not supposed to work in XHTML,
you (also) need .disabled="disa bled" there.

2. Repeated lookups of the same object reference should be avoided
as such is inefficient; assign the reference to a local variable
and use that variable instead. If you use references within
a repeated block, assign the reference outside of the repeated
block if possible and feasible:

var
es = document.forms["frmPost"].elements,
hwreq = es["hwreqested "];

es["employeena me"].className = "disabled";
...

for (var i = 0; i < 8; i++)
{
hwreq[i].disabled = true;
}
[color=blue]
> </Script>[/color]

While the case of an element type identifier case does not matter in SGML
based markup languages like HTML, it does matter in XML based markup
languages like XHTML. Therefore, one should develop the habit of having
element type and attribute identifiers, and attribute values lowercased
where possible; especially, one should avoid mixing case with(in) the
start tag and the end tag of an element.
[color=blue]
> <body onLoad="Disable _All();">[/color]

See above for how this event handler attribute value affects usability
of the document.

PointedEars

**Richard Cornford** · Jul 23 '05, 09:00 PM

Re: keep form elements enabled on "back&quot ; request

Thomas 'PointedEars' Lahn wrote:
<snip>[color=blue]
>for (var i = 0;i<8;i++)
>{
> document.forms["frmPost"].elements["hwreqested "][i].disabled = true;
>}
>
> instead. Note that .disabled=true is not supposed to work in
> XHTML, you (also) need .disabled="disa bled" there.[/color]
<snip>

..disabled = true - most certainly is expected to work in an XHTML DOM.
The HTML DOM specification states that the disabled property of the
HTMLInputElemen t interface is a boolean property, and includes no
special notes for XHTML DOM implementations .

The - disabled - attribute in XHTML mark-up might differ from HTML but
there is no reason to expect that to carry through to the type, and
value, of the - disabled - property in the DOM, especially as the
attribute has no representation of not-disabled.

Richard.

**RobG** · Jul 23 '05, 09:00 PM

Re: keep form elements enabled on "back&quot ; request

Thomas 'PointedEars' Lahn wrote:
[...][color=blue]
> 2. because you do not have control over the user agent's cache usage,
> you cannot assume any of the described behavior of a Back (button)
> feature, if there is any. Especially, onload scripts are not executed
> when using that feature and the document is accessed on the local cache.[/color]

onload scripts are executed[1] in both IE and Firefox when the 'back'
and 'forward' buttons are used.

[1] insert the usual caveat regarding script execution where the
browser can't or won't execute the script.

[...]

--
Rob

**Thomas 'PointedEars' Lahn** · Jul 23 '05, 09:01 PM

Re: keep form elements enabled on "back&quot ; request

Richard Cornford wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote:
> <snip>[color=green]
>> for (var i = 0;i<8;i++)
>> {
>> document.forms["frmPost"].elements["hwreqested "][i].disabled = true;
>> }
>>
>> instead. Note that .disabled=true is not supposed to work in
>> XHTML, you (also) need .disabled="disa bled" there.[/color]
> <snip>
>
> .disabled = true - most certainly is expected to work in an XHTML DOM.
> The HTML DOM specification states that the disabled property of the
> HTMLInputElemen t interface is a boolean property, and includes no
> special notes for XHTML DOM implementations .[/color]

Right. However, it reproducably does not work in some implementations
I have encountered when reading newsgroups. Yes, such could be considered
borken. No, they are not this seldom. No, I also would have to use Google
to find out what they exactly were. Sorry.

PointedEars

**Richard Cornford** · Jul 23 '05, 09:01 PM

Re: keep form elements enabled on "back&quot ; request

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Thomas 'PointedEars' Lahn wrote:
>> <snip>[color=darkred]
>>> for (var i = 0;i<8;i++)
>>> {
>>> document.forms["frmPost"].elements["hwreqested "][i].disabled =
>>> true; }
>>>
>>> instead. Note that .disabled=true is not supposed to work in
>>> XHTML, you (also) need .disabled="disa bled" there.[/color]
>> <snip>
>>
>> .disabled = true - most certainly is expected to work in an XHTML
>> DOM. The HTML DOM specification states that the disabled property
>> of the HTMLInputElemen t interface is a boolean property, and
>> includes no special notes for XHTML DOM implementations .[/color]
>
> Right. However, it reproducably does not work in some
> implementations I have encountered when reading newsgroups.
> Yes, such could be considered borken. No, they are not this
> seldom. No, I also would have to use Google to find out what
> they exactly were. Sorry.[/color]

Not that reproducible without the name of the UA.

Richard.

keep form elements enabled on "back" request

keep form elements enabled on "back" request

Comment

Comment

Comment

Comment

Comment