468,136 Members | 1,432 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,136 developers. It's quick & easy.

Correct Way to Reference Children of a DIV?

What is the correct way to find all the form elements in a particular
div? I'd like to be able to loop through them and disable them. For
example:

<form>
<div id="div1">
<input type=text name="a">
<input type=text name="b">
</div>

<div id="div2">
<input type=text name="c">
<input type=text name="d">
</div>

</form>

I'd like to be able to pass "div1" to a function and have it disable
text boxes a and b.

Thanks in advance for any help or ideas.

Nov 3 '05 #1
17 2136

er*******@gmail.com wrote:
What is the correct way to find all the form elements in a particular
div? I'd like to be able to loop through them and disable them. For
example:

<form>
<div id="div1">
<input type=text name="a">
<input type=text name="b">
</div>

<div id="div2">
<input type=text name="c">
<input type=text name="d">
</div>

</form>

I'd like to be able to pass "div1" to a function and have it disable
text boxes a and b.

Thanks in advance for any help or ideas.


One option is to use the standard DOM methods:-

var eDIV=document.getElementById("div1");
var cINPUTS=eDIV.getElementsByTagName("INPUT");

Julian

Nov 3 '05 #2


er*******@gmail.com wrote:

<div id="div1">
<input type=text name="a">
<input type=text name="b">
</div> I'd like to be able to pass "div1" to a function and have it disable
text boxes a and b.


With the W3C DOM (implemented in IE 5 and later, Netscape 6 and later,
Mozilla 1.0 and later, Opera 7 and later and other newer browsers like
Safari) every element has a method
getElementsByTagName
to find descendant elements by their tag name thus if you have an
element object then
elementObject.getElementsByTagName('input')
return a node list with all descendant elements with the tagName input.
So you can loop through that node list e.g.
var inputElements = elementObject.getElementsByTagName('input');
for (var i = 0; l = inputElements.length; i < l; i++) {
inputsElements[i].disabled = true;
}

Of course there are other form controls like textarea or select elements
for which you would need to look with additional calls to
getElementsByTagName.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Nov 3 '05 #3
VK

er*******@gmail.com wrote:
What is the correct way to find all the form elements in a particular
div? I'd like to be able to loop through them and disable them. For
example:

<form>
<div id="div1">
<input type=text name="a">
<input type=text name="b">
</div>

<div id="div2">
<input type=text name="c">
<input type=text name="d">
</div>

</form>

I'd like to be able to pass "div1" to a function and have it disable
text boxes a and b.

Thanks in advance for any help or ideas.

I think you may start from the proper form layout. Form elements and
DIV's are not in direct parent-child relations: they just can be forced
to overlap each other like in your case. It may hurt you during dynamic
form manipulations. The rest as suggested by the previous poster.

<html>
<head>
<title>Form</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">

<script type="text/javascript">
function getBlock1() {
var d = document.getElementById('fs1');
var a =d.getElementsByTagName('INPUT');
// ...
}
</script>

</head>

<body onload="getBlock1()">

<form>
<fieldset id="fs1">
<legend>Block 1</legend>
<input type=text name="a">
<input type=text name="b">
</fieldset>
<fieldset id="fs2">
<legend>Block 2</legend>
<input type=text name="c">
<input type=text name="d">
</fieldset>
</form>

</body>
</html>

Nov 3 '05 #4
Thanks to everyone who has helped me. Here's something I don't
understand:

VK wrote:

I think you may start from the proper form layout. Form elements and
DIV's are not in direct parent-child relations: they just can be forced
to overlap each other like in your case.


Wait a minute! Any large form is going to *have* to be broken up by
divs, spans, tables, etc. I can't believe that's wrong! It's
practically required!

Are you saying that you never have anything but form elements between
the begin and end form tags? How do you, for example, line up a bunch
of checkboxes into columns? A few divs, floated right, is perfect for
something like that.

it's obvious you know what you're talking about so I'm not arguing.
I'm just kind of blown away by this.

Nov 3 '05 #5
VK wrote:
er*******@gmail.com wrote: <snip>
<form>
<div id="div1">
<input type=text name="a">
<input type=text name="b">
</div>

<div id="div2">
<input type=text name="c">
<input type=text name="d">
</div>

</form>

<snip> I think you may start from the proper form layout. Form
elements and DIV's are not in direct parent-child relations:
they just can be forced to overlap each other like in your
case. It may hurt you during dynamic form manipulations.
Utter nonsense. That HTML is completely fine and valid, even by the
strict DTD.
The rest as suggested by the previous poster.

<snip>

So another VK 'contribution' that can only hinder the OP's
understanding.

Richard.
Nov 3 '05 #6
er*******@gmail.com wrote:
VK wrote:
I think ...
<snip>
it's obvious you know what you're talking about
Martin Honnen knows what he is talking about and I suspect that Julian
Turner knows enough not to talk about what he doesn't know, but VK is a
very different story. In statistical terms you would be better off (more
often than not correct) assuming that anything VK says is false,
inadequate or misconceived.
so I'm not arguing.
I'm just kind of blown away by this.


Feel free to argue, is it were true there would be something to back it
up.

Richard.
Nov 3 '05 #7
VK

er*******@gmail.com wrote:
Thanks to everyone who has helped me. Here's something I don't
understand:
VK wrote:

I think you may start from the proper form layout. Form elements and
DIV's are not in direct parent-child relations: they just can be forced
to overlap each other like in your case.
Wait a minute! Any large form is going to *have* to be broken up by
divs, spans, tables, etc. I can't believe that's wrong! It's
practically required!

Are you saying that you never have anything but form elements between
the begin and end form tags? How do you, for example, line up a bunch
of checkboxes into columns? A few divs, floated right, is perfect for
something like that.

it's obvious you know what you're talking about so I'm not arguing.
I'm just kind of blown away by this.


Don't get so exaggerated. My suggestion was about the *posted code*
where I see two blocks of the same form which you're trying to separate
visually(?) and functionally(?).

The golden rule is to try to solve the problem in easy and possibly
correct way first.
If not - then try to solve it in a not so easy and possibly
non-standard way.
For the posted code table layout was not requested, so internal
subdivisions using <fieldset> were totally logical *and* more correct
then <div> because <fieldset> *is* direct form's child and direct
parent to its elements. Just check and compare myDiv.form and
myFieldset.form property.
Naturally in design one *has* to use tables for nearly any form for
nice looking scalable layout. I'm personally using it since 1997and
over the passed years I had to place form elements to the most
fantastic places - not only tables. :-)

Richard Cornford wrote: ... some offensive off-topic stuff I'm not going to waste my time to comment on.


Nov 3 '05 #8
"VK" <sc**********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

er*******@gmail.com wrote:
Thanks to everyone who has helped me. Here's something I don't
understand:
VK wrote:
>
> I think you may start from the proper form layout. Form elements and

<snipped/>
Naturally in design one *has* to use tables for nearly any form for nice looking scalable layout. I'm personally using it since 1997and
over the passed years I had to place form elements to the most
fantastic places - not only tables. :-)


Naturally, you meant to say:
"...in design one *has* to use divs/spans for nearly any form
for nice looking scaleable layout..."?

Tables are in a semantic document for presenting tabular data,
not for positioning elements.

For that, we have css.

--
Dag.

Nov 3 '05 #9
VK
> "VK" <sc**********@yahoo.com> wrote in message
Naturally in design one *has* to use tables for nearly any form for
nice looking scalable layout. I'm personally using it since 1997and
over the passed years I had to place form elements to the most
fantastic places - not only tables. :-)

Dag Sunde wrote: Naturally, you meant to say:
"...in design one *has* to use divs/spans for nearly any form
for nice looking scaleable layout..."?

Tables are in a semantic document for presenting tabular data,
not for positioning elements.

For that, we have css.


CSS is not suitable for scaleable layout, this path has been explored
throughout during 4th versions on positioned elements and on the Java
1.x GridBagLayout
It failed to work and abandonned now in favor of the original
"invisible table" technique.
When did you last time visited the Web?
But it doesn't mean that we need to use table *every single time* some
positionning is needed.

Nov 3 '05 #10
VK wrote:
CSS is not suitable for scaleable layout, [...]
Rubbish. Utter nonsense. As usual from you.
When did you last time visited the Web?


When did you? 5 or more years ago? Go away.
PointedEars
Nov 3 '05 #11
"VK" <sc**********@yahoo.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
"VK" <sc**********@yahoo.com> wrote in message
Naturally in design one *has* to use tables for nearly any form for
> nice looking scalable layout. I'm personally using it since 1997and
> over the passed years I had to place form elements to the most
> fantastic places - not only tables. :-)


Dag Sunde wrote:
Naturally, you meant to say:
"...in design one *has* to use divs/spans for nearly any form
for nice looking scaleable layout..."?

Tables are in a semantic document for presenting tabular data,
not for positioning elements.

For that, we have css.


CSS is not suitable for scaleable layout, this path has been explored
throughout during 4th versions on positioned elements and on the Java
1.x GridBagLayout
It failed to work and abandonned now in favor of the original
"invisible table" technique.
When did you last time visited the Web?
But it doesn't mean that we need to use table *every single time* some
positionning is needed.


Ehh...

I am very suprised to hear that!

My work consists mainly of design and development, with a lot of weight
on the design part. The target is usually the web (but not neccessarily).

3-4 years ago I stopped completely to use tables for page-layout,
and started using CSS instead. I have no problems whatsoever in
implementing any design whith CSS instead of tables.

In addtion, maintenance and extension have become downright pleasant
now that there is no "garbage" concerning Layout (or "looks") in the
pages themselves.

I think you are very alone in having "abandoned" CSS where most other
are just coming up to speed using it.

And the comment: "When did you last time visited the Web?" just
collapses in my opinion (as a professional designer and programmer).

--
Dag.

Nov 3 '05 #12
VK

Dag Sunde wrote:
I am very suprised to hear that!

My work consists mainly of design and development, with a lot of weight
on the design part. The target is usually the web (but not neccessarily).

3-4 years ago I stopped completely to use tables for page-layout,
and started using CSS instead. I have no problems whatsoever in
implementing any design whith CSS instead of tables.

In addtion, maintenance and extension have become downright pleasant
now that there is no "garbage" concerning Layout (or "looks") in the
pages themselves.

I think you are very alone in having "abandoned" CSS where most other
are just coming up to speed using it.

And the comment: "When did you last time visited the Web?" just
collapses in my opinion (as a professional designer and programmer).


I guess it's going to be the question of preferences (until directly
prohibited by standards / not supported by browsers). You know mines -
I know yours. As the topic is not called "Correct way to build pages":
I'd like to apologize if my expressions were semi-provocative and close
this discussion within this thread. (?)

Nov 3 '05 #13
VK
> VK wrote:
CSS is not suitable for scaleable layout, [...]

Thomas 'PointedEars' Lahn wrote: Rubbish. Utter nonsense. As usual from you.


Hah, one of my hard case patients... Any *modern* links by occasion for
non-table based more-or-less known sites? ("mission statement" sites
like w3.org please out)

Nov 3 '05 #14
VK wrote:

Will you please learn how to quote in Usenet? <http://jibbering.com/faq/>

[Quotation corrected]
Thomas 'PointedEars' Lahn wrote:
VK wrote:
> CSS is not suitable for scaleable layout, [...]

Rubbish. Utter nonsense. As usual from you.


Hah, one of my hard case patients... Any *modern* links by occasion for
non-table based more-or-less known sites? ("mission statement" sites
like w3.org please out)


The question itself is biased, I will not answer it "as is". I do not have
to provide a site that does not qualify as "mission statement site" by your
humble standards.

a) You are the one with the thesis (that CSS is not suitable for scalable
layouts), you are to prove it. But then, shifting the burden of proof
is a logical fallacy I am not wondered of experiencing from you,
especially on this subject.

b) Since we are not talking about percents of usage of a technique (CSS)
but of applicability of a technique (CSS) to a problem (scalable layout),
I can show you *any* site that successfully uses CSS in order to prove
my point (even though I am not obliged to that in matters of conduct of
discussion).

Here you are:

<http://www.csszengarden.com/>

You can use your favorite search robot to find more examples.
I will be not your assistant in turning the point in question around.
PointedEars
Nov 3 '05 #15
VK wrote:
er*******@gmail.com wrote:
Thanks to everyone who has helped me.
Here's something I don't understand:
VK wrote:
<snip> For the posted code table layout was not requested, so
internal subdivisions using <fieldset> were totally logical
*and* more correct then <div> because <fieldset> *is* direct
form's child and direct parent to its elements. Just check
and compare myDiv.form and
myFieldset.form property.

<snip>

The existence of the - form - property of the W3C HTML Level 1 DOM
specified - HTMLFieldSetElement - interface does not suggest that
FIELDSET elements should be children of FORM elements. Indeed as the
specification states that the - form - property "Returns null if this
control is not within the context of a form" the implication is that a
FIELDSET is not even expected in a FORM in all cases.

As to whether a FIELDSET element is a "more correct" child of a FORM
than a DIV, and the proposal that a FIELDSET "*is* direct form's child
and direct parent to its elements", The strict HTML DTD defines a form
as:-

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

- and the transitional DTD as:-

<!ELEMENT FORM - - (%flow;)* -(FORM) -- interactive form -->

So in the strict DTD the direct children of a FORM must be %block and/or
SCRIPT elements, excluding FORM elements. And in the transitional DTD
the direct children may be %flow elements, excluding FORM.

The Strict DTD defines %block as:-

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

- in which DIV and FIELDSET have equal significance.

While the transitional DTD defines %flow as:-

<!ENTITY % flow "%block; | %inline;">

- and %block as:-

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | CENTER |
NOSCRIPT | NOFRAMES | BLOCKQUOTE | FORM | ISINDEX | HR |
TABLE | FIELDSET | ADDRESS">

- where, again, DIV and FRAMESET have equal status.

The only distinction between the two are their respective semantic
meanings. The DIV element is a semantically neutral division (of
arbitrary page content). As to the meaning of FIELDSET, the text of the
HTML specification says:-

"The FIELDSET element allows authors to group thematically related
controls and labels. Grouping controls makes it easier for users to
understand their purpose while simultaneously facilitating tabbing
navigation for visual user agents and speech navigation for
speech-oriented user agents. The proper use of this element makes
documents more accessible."

The application of semantic mark-up involves the assignment of meaning
by its (human) author, and the observation that the controls within a
form are divided into two divisions is not enough to determine that the
division should mean that the controls are in two "thematic" groups.

So the test of correctness between DIV and FIELDSET hangs on the
author's perception of the contained form controls as "thematically
related" to each other while not "thematically related" to those in the
other division.

Turning to the FIELDSET element's DTD entry, both DTDs define FIELDSET
as:-

<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*)
-- form control group -->

And so the permissible content for FIELDSET is #PCDATA and LEGEND and
%flow elements.

So a FIELDSET may be the direct child of a FORM, but it may also be a
descendant of a FORM and it may also appear in any other element that
allows %block content and outside of any FORM. And form controls may be
direct children of a FIELDSET, but they may also be descendants of a
FIELDSET and they may also appear in many contexts outside of a
FIELDSET.

If a FIELDSET "*is* direct form's child and direct parent to its
elements" it would be possible for the DTD to express that restriction
so the fact that neither of them does suggests that the assertion is
false, incomplete or misconceived.

Richard.
Nov 4 '05 #16
Richard Cornford wrote:
VK wrote:
er*******@gmail.com wrote:
Thanks to everyone who has helped me.
Here's something I don't understand:
VK wrote:

<snip>
For the posted code table layout was not requested, so
internal subdivisions using <fieldset> were totally logical
*and* more correct then <div> because <fieldset> *is* direct
form's child and direct parent to its elements. Just check
and compare myDiv.form and
myFieldset.form property.

<snip>

The existence of the - form - property of the W3C HTML Level 1 DOM
specified - HTMLFieldSetElement - interface does not suggest that
FIELDSET elements should be children of FORM elements.


W3C DOM Level 1 HTML (which is the correct [order of] term[s])
has been rendered obsolete by the W3C "Document Object Model (DOM)
Level 2 HTML Specification"[1], as I mentioned in my latest
contribution to the FAQ.

However, your statement also holds true for the latter.
PointedEars
___________
[1] <http://www.w3.org/TR/DOM-Level-2-HTML/>
Nov 4 '05 #17

Richard Cornford wrote:
I suspect that Julian Turner knows enough not to talk about what he doesn't know


As an amateur (a lawyer by day) I aim to achieve this as much as
possible, with the occasional opinion ventured when feeling foolhardy.

Julian

Nov 7 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Raghuraman | last post: by
5 posts views Thread by JC | last post: by
1 post views Thread by Guogang | last post: by
2 posts views Thread by Martin Ortiz | last post: by
2 posts views Thread by Al in Dallas | last post: by
5 posts views Thread by RioRanchoMan | last post: by
6 posts views Thread by stephen.cunliffe | last post: by
27 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.