Finding a Form Element from an Input

[kelvin.jones]

Hi, if I had the ID of an input element, how can I find the input's
FORM in javascript?

Basically, given a input's dom id, I want to insert something in the
onSubmit of the Form that that input is in. I want to avoid making the
user have to submit the form's id if possible.

Let me know if my question is unclear...thanks!

Kel

 

[Evertjan.]

wrote on 30 jul 2006 in comp.lang.javascript:

Hi, if I had the ID of an input element, how can I find the input's
FORM in javascript?

<form id=f name=ff>
<input id=x>
</form>

<script type='text/javascript'>
var x = document.getElementById('x')
alert(x.form.id) // returns f
alert(x.form.name) // returns ff
</script>

 

[Lasse Reichstein Nielsen]

<form id=f name=ff>

Just to be pedantic (can't let an error go uncommented
the "name" and "id" attributes of a "form" element must be
identical in valid HTML.
<URL:http://www.w3.org/TR/html4/struct/links.html#h-12.2.3>

/L

 

[Keepon Keepinon]

Nice...Silly of me to not try just viewing the properties of the input
element in a debugger! Thanks

Kel

 

[Evertjan.]

Lasse Reichstein Nielsen wrote on 30 jul 2006 in comp.lang.javascript:

Just to be pedantic (can't let an error go uncommented
the "name" and "id" attributes of a "form" element must be
identical in valid HTML.
<URL:http://www.w3.org/TR/html4/struct/links.html#h-12.2.3>

Ah, yes, "valid HTML".

But does the rule have a reason beond semantics and
is it implemented on a mainstream browser?

[Personally I could do with loosing "name" alltogether
and using only "id", so agreeing with w3's feelings.]

 

[Michael Winter]

Lasse Reichstein Nielsen wrote on 30 jul 2006 in comp.lang.javascript:
[snip]

...the "name" and "id" attributes of a "form" element must be
identical in valid HTML.

[snip]

But does the rule have a reason beond semantics and
is it implemented on a mainstream browser?

What would you expect a browser to do if it 'implemented' that rule? A
browser could do just about anything when encountering invalid markup. A
slightly more reasonable expectation might have the browser expose the
form in the forms collection by only one of those identifiers, but
that's unlikely happen; it's just as easy to expose both.

The better question to ask is, "Why use different values?" Both
attributes serve to identify a form to a script, though the id attribute
also permits the form to function as a destination anchor. The only
reason to continue using the name attribute is to support obsolete
browsers like NN4 that won't expose the form by id alone. What value
would there be in forms['id-identifier'] and forms['name-identifier'] as
two independent approaches to the same objective, in the same script?

Of course, it's not infrequently the case that both can be omitted when
manipulation of the form is driven by form-related events.

[snip]

Mike

 

[Evertjan.]

Michael Winter wrote on 01 aug 2006 in comp.lang.javascript:

What value
would there be in forms['id-identifier'] and forms['name-identifier'] as
two independent approaches to the same objective, in the same script?

True.

So can we forget name and use only "id" in modern browsers?

Not in:

<form><input id="Textinput">

 

[Richard Cornford]

No they don't.

7.5.2
The id attribute shares the same name space as the name attribute _when
used for anchor names_.

http://www.w3.org/TR/html4/struct/global.html#adef-id

What about:-

<quote = cite="http://www.w3.org/TR/html4/struct/links.html#h-12.2.3">
It is permissible to use both attributes to specify an element's unique
identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME,
IMG, and MAP. When both attributes are used on a single element, their
values must be identical.
<quote>

- which explicitly stats that it is permissible to use both a NAME and
an ID on FORM elements, but that both must have the same value.

Richard.

 

[Michael Winter]

On 01/08/2006 14:29, Evertjan. wrote:

[To identify form elements]

So can we forget name and use only "id" in modern browsers?

That's the idea.

Not in:

<form><input id="Textinput">

Yes. The name attribute is still specifies the control name for form
controls. It's also still used with other elements like param and meta.

Mike

 

[Randy Webb]

Jim Land said the following on 8/1/2006 6:15 PM:

Well, yes, but your quotation appears as a note in the section on A tags.

But it clearly says it applies to A, APPLET, FORM, FRAME, IFRAME, IMG
and MAP elements.

If this were really true, one would expect to find the details by
examining each of the tags named.

Are you kidding? Duplicate it all over the place?

But in fact there is no such prohibition in the sections which
define APPLET, FORM, FRAME, IFRAME, IMG, or MAP tags.

In fact, trying to validate a form element with a NAME attribute under
HTML4.01 Strict gets an error from the validator:

Error Line 12 column 11: there is no attribute "NAME".
<form name="myForm" id="myID" action="somewhere">

 

[Michael Winter]

Jim Land said the following on 8/1/2006 6:15 PM:

news:[email protected]:

[snip]
[snip]

Well, yes, but your quotation appears as a note in the section on A tags.

What bearing does that have upon the statement that when "both [name and
id] attributes are used on a single element, their values must be
identical"?

The section (12.2.3 Anchors with the id attribute) notes that both
attributes share the same namespace; two different elements cannot use
either attribute to declare a duplicate identifier. As the name
attribute on the other listed elements acts as an identifier, the same
usage rules apply to them, too: the id and name attribute values must be
identical on the same element, and the resulting identifier must be
unique within a document.

[snip]

There doesn't need to be. Defining it once is enough.

In fact, trying to validate a form element with a NAME attribute under
HTML4.01 Strict gets an error from the validator:

I'm not sure what you did to reach that conclusion, Randy, but your test
was faulty. Form elements may have name attributes in all 'versions' of
HTML 4. Check the DTDs, if you like.

Versions of XHTML, on the other hand, (probably 1.1+ - I'm not going to
look ) have removed the name attribute from many elements (form
controls being an obvious exception).

Mike

 

[Randy Webb]

Michael Winter said the following on 8/2/2006 5:03 PM:

On 01/08/2006 23:20, Randy Webb wrote:



I'm not sure what you did to reach that conclusion, Randy, but your test
was faulty.

My test was faulty? I merely went to the W3C's validator and attempted
to validate this HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>Blank Test Page</title>
</head>
<body>
<form name="myForm" action="somewhere">
<input id="myInput">
</form>
</body>
</html>


And received three error messages, the first being:

Error Line 7 column 11: there is no attribute "NAME".
<form name="myForm" action="somewhere">

You can validate it for the other 2, they deal with INPUT not being
allowed there and the FORM not being closed. But since the above error
is the first, that is always the first error to correct. Removing the
name attribute and re-validating corrects that error. So, how is my test
"faulty" when the W3C's validator gives me the results I posted?

Or, does that mean the W3C doesn't even know what it's own documentation
says?

 

[Michael Winter]

Michael Winter said the following on 8/2/2006 5:03 PM:
[snip]

My test was faulty? ...

My apologies. It seems that you chose a document type where form
elements do not have a name attribute. The attribute is also missing
from img elements. In both cases, the attribute was added between the
1998 HTML 4.0 Recommendation and the 1999 HTML 4.01 Proposed
Recommendation. I wasn't aware that such changes took place; I always
thought that the remark that accompanies the attributes in the prose:

Note. This attribute has been included for backwards
compatibility. Applications should use the id attribute to
identify elements.

was a historic remark. Clearly not.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">

Incidentally, the formal public identifier and the system identifier are
out-of-sync as the latter identifies HTML 4.01. An SGML processor is
allowed to use the FPI to retrieve a DTD, and it obviously does in this
case.

[snip]

Mike