Creating new form elements on a webpage

[Bill H]

Is it possible with JavaScript to create new form elements on a
webpage that has already loaded in the browser? For example, what I am
hoping to do is have a text field for a name and a link that lets them
add another text field for another name etc. I believe I can do this
on a DIV but haven't looked at coding it yet. Any thoughts, pointers
etc?

Bill H

 

[Martin Honnen]

Is it possible with JavaScript to create new form elements on a
webpage that has already loaded in the browser? For example, what I am
hoping to do is have a text field for a name and a link that lets them
add another text field for another name etc. I believe I can do this
on a DIV but haven't looked at coding it yet. Any thoughts, pointers
etc?

Learn about document.createElement and appendChild (or insertBefore) e.g.
var input = document.createElement('input');
input.type = 'text';
input.id = 'input1';
input.name = 'input1';
var label = document.createElement('label');
label.appendChild(document.createTextNode('Name? '));
label.appendChild(input);
someFormElement.appendChild(label);

 

[Thomas 'PointedEars' Lahn]

Learn about document.createElement and appendChild (or insertBefore) e.g.
var input = document.createElement('input');
input.type = 'text';
input.id = 'input1';

Note that providing an ID here might interfere with existing stylesheets.
However, an ID for a control can be useful if the `for' attribute is used
on a `label' element, so that the control can be activated by activating
its associated label. See below.

input.name = 'input1';

Given that the OP asked about extending an *existing* form, it may
be possible that an element of the chosen name already exists, and
so this line or a similar one causes a run-time error in IE. See

var label = document.createElement('label');
label.appendChild(document.createTextNode('Name? '));
label.appendChild(input);

The `input' element should not be the child element of a `label' element;
it should be following it (as next sibling or otherwise), so that the
`for' attribute and the form control activation mechanism works reliably:

<label for="foo">Bar: </label><input ... id="foo">

http://www.w3.org/TR/html401/interact/forms.html#adef-for

someFormElement.appendChild(label);

All DOM methods should of course be feature-tested before being called, and
all element object references should be subject to a type-converting test
before being used.

Such as:

/**
* @see http://pointedears.de/scripts/types.js
*/
function isMethodType(s)
{
return /\b(function|object)\b/i.test(s);
}

var input, label;
if (isMethodType(typeof document.createElement) && document.createElement
&& (input = document.createElement('input'))
&& ...)
{
...
}


See also http://pointedears.de/scripts/test/whatami


PointedEars

 

[Martin Honnen]

The `input' element should not be the child element of a `label' element;
it should be following it (as next sibling or otherwise),

A label without a for attribute applies to its content: "When [the for
attribute is] absent, the label being defined is associated with the
element's contents." "To associate a label with another control
implicitly, the control element must be within the contents of the LABEL
element. In this case, the LABEL may only contain one control element."
so it is perfectly fine to put the input into the label.

 

[Thomas 'PointedEars' Lahn]

The `input' element should not be the child element of a `label' element;
it should be following it (as next sibling or otherwise),

A label without a for attribute applies to its content: "When [the for
attribute is] absent, the label being defined is associated with the
element's contents." "To associate a label with another control
implicitly, the control element must be within the contents of the LABEL
element. In this case, the LABEL may only contain one control element."
so it is perfectly fine to put the input into the label.

I would still not do it, for the sake of semantics and thus for
accessibility. A control is not a part of its label.


PointedEars

 

[Gregor Kofler]

Martin Honnen meinte:

Learn about document.createElement and appendChild (or insertBefore) e.g.
var input = document.createElement('input');
input.type = 'text';
input.id = 'input1';
input.name = 'input1';

You should also mention, that IE has it's problems with that, and will
not set the name of the element properly (and not deliver the elements
value on submitting the form).

Gregor

[1]
<http://msdn.microsoft.com/library/d.../author/dhtml/reference/properties/name_2.asp>

 

[RobG]

Clicking on a label puts focus on the control.

"When a LABEL element receives focus, it passes
the focus on to its associated control."

<URL: http://www.w3.org/TR/html4/interact/forms.html#edef-LABEL >


That is seen by many as assisting usability, paticularly for checkboxes
and radio buttons, less so for text inputs. I've haven't found anyone
who thought that behaviour was detrimental to usability, but I guess
there's a first for everything.

To achieve the above in IE 6, the control *must* be a child of the label
and the label and control must have matching for and id attributes
respectively.

A label without a for attribute applies to its content: "When [the for
attribute is] absent, the label being defined is associated with the
element's contents." "To associate a label with another control
implicitly, the control element must be within the contents of the LABEL
element. In this case, the LABEL may only contain one control element."
so it is perfectly fine to put the input into the label.

And that would be nice if IE followed the rules. :-(

I would still not do it, for the sake of semantics and thus for
accessibility. A control is not a part of its label.

It is your prerogative to hold that opinion, others (very reasonably)
think otherwise.

 

[RobG]

Martin Honnen meinte:

You should also mention, that IE has it's problems with that, and will
not set the name of the element properly (and not deliver the elements
value on submitting the form).

IE successfully sets the name attribute and will submit the element
according to the usual rules, however the element is inaccessible via
the name attribute, i.e.

document.form.input1

will return undefined.

[1]
<http://msdn.microsoft.com/library/d.../author/dhtml/reference/properties/name_2.asp>

As with many articles on MSDN, that reference is incomplete and incorrect.

 

[RobG]

RobG wrote:
[...]

To achieve the above in IE 6, the control *must* be a child of the label
and the label and control must have matching for and id attributes
respectively.

Ooops, IE only requires matching for and id attributes, the control
doesn't need to be a child of the label.

But IE doesn't successfully associate the control with the label if
there aren't matching for and id attributes, even if the control is a
child of the label.

 

[Gregor Kofler]

RobG meinte:

Gregor Kofler wrote:

IE successfully sets the name attribute and will submit the element
according to the usual rules, however the element is inaccessible via
the name attribute, i.e.

document.form.input1

will return undefined.

You're right. I mixed that up.

Gregor

 

[Thomas 'PointedEars' Lahn]

I would still not [make the control a child element of the `label' element],
for the sake of semantics and thus for accessibility. A control is not a
part of its label.

It is your prerogative to hold that opinion, others (very reasonably)
think otherwise.

I know that examples are not normative, but even the HTML 4.01 Specification
uses a sibling in the example for the `label' element. Implementors might
not know the aforementioned restriction (as displayed e.g. by the continued
implementation of supposed script-hiding comments in new UAs), so I also
deem it unwise for that reason not to follow that example.


PointedEars