Disabling Form Elements

[shankwheat]

I have a function which passes text from txtdebt to debtsbox which
works fine. However, I want to add code which examines the value of
debtsbox and if any of the values the user entered contain the string
"d" then I want to emable rblDebts which is disabled when the page
loads. This part is not working (no errors) and I'm not sure why.
Thanks.

<script type="text/javascript" language="JavaScript">
<!-- Begin
oldvalue = "";
function passText(passedvalue) {
if (passedvalue != "") {
var totalvalue = passedvalue+"\n"+oldvalue;
document.form1.debtsbox.value = totalvalue;
oldvalue = document.form1.debtsbox.value;
}

var searchfor = "d";
if (oldvalue.search(searchfor) > -1) {
document.form1.rblDebts.disabled = false;
} else
document.form1.rblDebts.disabled = true;
}
// End -->
</script>

<form id="form1">
Debt ID: <input type="text" name="txtdebt" maxlength="5" />
<input type="button" value="Add to list" class="buttonstyle2"
onClick="passText(this.form.txtdebt.value);">

Debts added to your list:
<textarea cols="40" rows="5" name="debtsbox" ></textarea>

<input type="radio" id="rblDebts" disabled="true">

</form>

 

[nutso fasst]

<input type="radio" id="rblDebts" disabled="true">

One radio button makes no sense.

http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#radio

nf

 

[shankwheat]

Right..Adding a bunch of radio buttons wasn't relevant to my question.
What is important is that it's a form element.

 

[nutso fasst]

Right..Adding a bunch of radio buttons wasn't relevant to my question.
What is important is that it's a form element.

Ah, but in that case, doesn't rblDebts represent an array of form elements?
You can't disable an array. Try
document.form1.rblDebts[0].disabled = false
and see what happens.

nf

 

[nutso fasst]

Right..Adding a bunch of radio buttons wasn't relevant to my question.
What is important is that it's a form element.

Ah, but in that case, doesn't rblDebts represent an array of form elements?
You can't disable an array. Try
document.form1.rblDebts[0].disabled = false
and see what happens.

nf

Oh, and one other thing. Your form element needs a name before you can refer
to it as document.form1:

<form name="form1">

Using id, you'd need to refer to it by id, e.g.:

document.getElementById('form1').rblDebts[0].disabled = false

nf

 

[mick white]

shankwheat wrote:

[snip]

<input type="radio" id="rblDebts" disabled="true">

<input type="radio" id="rblDebts" disabled>

OR

<input type="radio" id="rblDebts" disabled="disabled" />

Mick.

 

[RobG]

elements?

No, it is an HTMLCollection of form controls:

<URL: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506 >

which has some similarities to an array, but is generally very
different.


Quite correct, but it isn't an array. Some browsers support disabling
all the controls in a form by setting a disabled attribute for the form
element, but it's not part of the W3C standard and is not widely
supported.

Try document.form1.rblDebts[0].disabled = false
and see what happens.

nf

Oh, and one other thing. Your form element needs a name before you can refer
to it as document.form1:

<form name="form1">

Using id, you'd need to refer to it by id, e.g.:

document.getElementById('form1').rblDebts[0].disabled = false

Not at all - in modern browsers either name or ID will do when using
the forms collection. Keep using names if old browsers need to be
supported. If an ID is used, the syntax must be:

document.forms.form1.rblDebts

which works for names too.

 

[nutso fasst]

No, it is an HTMLCollection of form controls:

<URL: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506 >

which has some similarities to an array, but is generally very
different.

I appreciate exegesis, Rob, but in this I'm dubious. If it were an
HTMLCollection it would have a namedItem method, and how can that be when
all nodes have the same name? In any case, relative to the OP's need to
access attributes, a list of nodes and an array are not at all different.

Using id, you'd need to refer to it by id, e.g.:

document.getElementById('form1').rblDebts[0].disabled = false

Not at all - in modern browsers either name or ID will do when using
the forms collection. Keep using names if old browsers need to be
supported. If an ID is used, the syntax must be:

document.forms.form1.rblDebts

which works for names too.

And so is clearly superior syntax, thank you. But it's not how the syntax
"must be" when the form element has an ID.
document.getElementById('form1').rblDebts also works in modern browsers.

In the OP's example the form had ID="form1" but his script referred to
document.form1.rblDebts, which is not correct syntax and will not work in
modern browsers.

nf

 

[ASM]

nutso fasst a écrit :

And so is clearly superior syntax, thank you. But it's not how the syntax
"must be" when the form element has an ID.

Usualy each element of a form has a name ... !

document.getElementById('form1').rblDebts also works in modern browsers.

If and *only* if 'form1' is really an id
(IE understanding name and id are same)
and if 'rblDebts' is itself a name (and not an id)

In the OP's example the form had ID="form1" but his script referred to
document.form1.rblDebts, which is not correct syntax and will not work in
modern browsers.

Right.

 

[RobG]

I appreciate exegesis, Rob

exegesis: critical explanation or interpretation of a text or portion
of a text, esp. of the Bible.

, but in this I'm dubious.

You should be certain that it isn't a javascript Array at least.

If it were an HTMLCollection it would have a namedItem method,
and how can that be when all nodes have the same name?

That logic isn't particularly convincing, did you test it? The object
returned by using dot property access to a set of radio buttons does in
fact have a namedItem method in IE, but not Firefox.

Firefox doesn't implement the namedItem method for forms either, but I
don't think you'd deduce from that that a form isn't a dinky-di
HTMLForm.

In any case, relative to the OP's need to access attributes, a list of
nodes and an array are not at all different.

That is about the only feature that they share, along with a
self-adjusting length property. Some people have come here wondering
why such "arrays" don't behave when asked to pop(), slice(), shift(),
etc.

HTML collections are *always* contiguous and start from zero, from
which can be deduced that if there is no item(0) (i.e. it is undefined)
then the length *must* be zero and also that you can't add an item
beyond an index equal to the length - neither of which is necessarily
true for an Array.

Using id, you'd need to refer to it by id, e.g.:

document.getElementById('form1').rblDebts[0].disabled = false

Not at all - in modern browsers either name or ID will do when using
the forms collection. Keep using names if old browsers need to be
supported. If an ID is used, the syntax must be:

document.forms.form1.rblDebts

which works for names too.

And so is clearly superior syntax, thank you. But it's not how the syntax
"must be" when the form element has an ID.
document.getElementById('form1').rblDebts also works in modern browsers.

The point was in regard to dot property access to the forms collection
using IDs. Where a name is used instead of, or in addition to, an ID
the syntax can be as the OP wrote.

In the OP's example the form had ID="form1" but his script referred to
document.form1.rblDebts, which is not correct syntax and will not work in
modern browsers.

Which is why I pointed out the correct syntax to use with IDs. It is
generally recommended to use the relevant collection, rather than
getElementById, when accessing forms and their controls.

 

[nutso fasst]

You should be certain that it isn't a javascript Array at least.

I used array generically: Computers. a block of related data elements, each
of which is usually identified by one or more subscripts.

That logic isn't particularly convincing, did you test it? The object
returned by using dot property access to a set of radio buttons does in
fact have a namedItem method in IE, but not Firefox.

So, what does namedItem(radiobuttons') refer to, the same collection from
which you derived it? That certainly is what occurs with dot notation, where
you can append dot names til bulls fly and you're still looking at the same
collection. Doesn't strike me as very logical behavior.

Try same-naming mixed radio and input checkbox types and see what happens.
Check a checkbox, then check an unchecked radio button. Which is more
logical, IE or FF?

Firefox doesn't implement the namedItem method for forms either, but I
don't think you'd deduce from that that a form isn't a dinky-di
HTMLForm.

From what I've grokked of the DOM, I think dot notation and nodelist[n]
indexing should be defined as shortcuts for namedItem and index methods,
i.e. .namedItem('name') == .name and list.item(n) == list[n]. Then it could
be said that FF implements the shortcut form of namedItem method.

I don't understand why, given two inputs named "input1" in form1,
document.forms.form1.input1[0].value
refers to the value property of the first, while, given two images named
"image1",
document.images.image1[0].src
throws an exception. Is there an explanation in the DOM spec of why
like-named form elements are a collection but like-named elements in other
HTMLCollections are not?

nf

 

[RobG]

I used array generically:

Fine, but the result is that some people reading it think "array" means
javascript Array. It is similar to the argument about Objects and
associative arrays.

[...]

So, what does namedItem(radiobuttons') refer to, the same collection from
which you derived it? That certainly is what occurs with dot notation, where
you can append dot names til bulls fly and you're still looking at the same
collection. Doesn't strike me as very logical behavior.

Regardless, your logic isn't proof that the object in question isn't an
HTMLCollection.

Try same-naming mixed radio and input checkbox types and see what happens.
Check a checkbox, then check an unchecked radio button. Which is more
logical, IE or FF?

I don't understand how that is relevant.

The original point of contention was whether the existence of a
namedItem method can be used as an indicator of whether or not the
object in question was an HTMLCollection. The fact that at least one
browser does implement the method supports the contention that it is.

When combined with the other observed behaviour, and relevant sections
of the W3C spec, the evidence is very strong that it is an
HTMLCollection. The fact that some other browser doesn't implement a
namedItem method is not proof that it isn't. That factor is weakened
when you consider that that browser also doesn't implement the method
on an object that clearly should have it according to the W3C spec.

I hope that makes sense.

Firefox doesn't implement the namedItem method for forms either, but I
don't think you'd deduce from that that a form isn't a dinky-di
HTMLForm.

From what I've grokked of the DOM, I think dot notation and nodelist[n]
indexing should be defined as shortcuts for namedItem and index methods,
i.e. .namedItem('name') == .name and list.item(n) == list[n]. Then it could
be said that FF implements the shortcut form of namedItem method.

All that can be inferred from that is Firefox (et al) implements
javascript dot property access to DOM HTMLElement object properties
(Firefox often restricts such access to only those attributes that are
specified in the relevant DTD and requires the use of getAttribute to
access other (non-standard) attributes).

I don't understand why, given two inputs named "input1" in form1,
document.forms.form1.input1[0].value
refers to the value property of the first, while, given two images named
"image1",
document.images.image1[0].src
throws an exception.

I suspect for backward compatibility. The original syntax (i.e. circa
Navigator 3) would have been:

document.image1[0].src;

which "works" in IE and Firefox (and is consistent with the access
scheme for form elements noted previously) but it assumes prior
knowledge that document.image1 will return a collection, otherwise
you'll get an error.

It is usually handled by something like:

var x = document.image1;
if ( typeof x.length == 'number' ){
/* got back a collection */
} else {
/* got back a single node */
}

It seems that with the introduction of a standardised DOM, support for
the old method was retained for backward compatibility and that new
syntax was introduced to use IDs and more explicitly address
collections, so that:

document.images

returns the collection and

document.images.<imageName_or_ID>

returns some member of that collection. It does seem inconsistent that
in this particular case, the name attribute behaves like an ID and only
returns a single node (in IE and Firefox at least) - there is probably
an old timer lurking who has an opinion about that.

Is there an explanation in the DOM spec of why
like-named form elements are a collection but like-named elements in other
HTMLCollections are not?

Not that I'm aware of - the behaviour you describe is browser specific.
In the above scenario and given:

var docImages = document.images;

docImages.namedItem('image1') returns a single element in Firefox, but
IE returns a collection of the like-named img elements. That seems
consistent with the behaviour of each browsers' implemenation of form
control collections.

Variations in the implementation of (and outright non-compliance with)
W3C standards is hardly uncommon. There is also a very wide range of
non-specified behaviours (e.g. DOM 0), so all that can be said is that
where compliance is claimed, things *should* behave as per the spec -
but expect that in reality they sometimes don't or wont and deal with
it (I'm sure Randy Webb is itching to make a comment about that ;-) ).