hidden input type and the dom

A

aidy.lewis

Hi,

Could someone tell me how I can reference a hidden input type using
the DOM?

Aidy
 
Y

y2ee.asdf

Hi,

Could someone tell me how I can reference a hidden input type using
the DOM?

Aidy
Click to expand...

You're hidden input needs to be in the following format:

<input type="hidden" id="myHiddenInput" value="myHiddenValue" />

Then you may reference is as follows:

var hiddenInput = document.getElementById("myHiddenInput");
alert(hiddenInput.value);

This will display myHiddenValue in an alert box.

Hope this helps.
 
R

Richard Cornford

You're hidden input needs to be in the following format:

<input type="hidden" id="myHiddenInput" value="myHiddenValue" />
Click to expand...

It would be wrong to include the slash at the end in an HTML document
(and as IE browsers do not comprehend XHTML it would not be a good idea
to contemplate writing, and especially scripting, XHTML documents).
Also, an INPUT element without a NAME attribute would not result in a
name value pair being sent to the server if the containing form was
submitted.
Then you may reference is as follows:

var hiddenInput = document.getElementById("myHiddenInput");
alert(hiddenInput.value);
Click to expand...
<snip>

It is always better to use the W3C HTML DOM specified - elements -
collection of the FORM element to reference the form controls it
contains. They can be referenced in that collection by NAME, ID or
index, but given that they must have a NAME attribute to be useful in
form submission it makes most sense to use that NAME attribute's value.
See:-

<URL: http://jibbering.com/faq/faq_notes/form_access.html >

Richard.
 
P

Peter Michaux

It would be wrong to include the slash at the end in an HTML document
Click to expand...

I ran into this a few days ago. The W3C validator allows the slash and
is happy without it also.

For example the following does validate.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Page Title</title>
</head>
<body>
</p>
Click to expand...
</form>
</body>
</html>

Peter
 
Y

y2ee.asdf

It would be wrong to include the slash at the end in an HTML document
(and as IE browsers do not comprehend XHTML it would not be a good idea
to contemplate writing, and especially scripting, XHTML documents).
Click to expand...

IE complains only when the XHTML is served as an xml document. When
served as HTML, it can render fine.
Also, an INPUT element without a NAME attribute would not result in a
name value pair being sent to the server if the containing form was
submitted.
Click to expand...

Agreed, but the question was with regards to referencing the hidden
input using JavaScript. Server-side processing of the form is a
different story.
<snip>

It is always better to use the W3C HTML DOM specified - elements -
collection of the FORM element to reference the form controls it
contains.
Click to expand...

<snip>

I would accept this if you could provide an official w3 recommendation
that supports it.

Thanks.
 
R

Richard Cornford

Peter said:
I ran into this a few days ago. The W3C validator allows the slash and
is happy without it also.
Click to expand...

The slash is valid in SGML, it just does not mean what it may be take to
mean. It is actually a shortcut for:-

<input type="hidden" id="myHiddenInput" value="myHiddenValue">&gt;

- though browsers do not recognise those SGML shortcuts, even if SGML
validators do. Try putting one inside the HEAD (on a LINK or META)
element and see if the validator does not complain about text appearing
in a context where text is not allowed (or the HEAD being explicitly
closed after it has been implicitly closed by the out of context text).

Richard.
 
R

Richard Cornford

IE complains only when the XHTML is served as an xml document.
Click to expand...

IE does not complain, it just applies an inbuilt XSLT to the XML of the
mark-up and displays the result as an HTML document that relates to the
XML source code.
When served as HTML, it can render fine.
Click to expand...

You mean that when you tell the browser that the document is HTML it
parses it with its tag-soup HTML parser and error-corrects all the
nonsense in the mark-up back to an HTML document that it can cope with?
That makes it an HTML document with correctable errors not an XHTML
document.

You are forgetting that our subject here is browser scripting so we have
an absolute test for whether a document is XHTML or HTML and that is
whether the receiving browser exposes an XHTML DOM or an HTML DOM to be
scripted. If the browser exposes an XHTML DOM then the document was an
XHTML document, if an HTML DOM then it was an HTML document. And as
almost no non-trivial browser scripts can cope with both XHTML and HTML
DOMs that distinction is very significant. IE browsers do not support
XHTML and so they just cannot expose an XHTML DOM to be scripted. And as
commercial scripting is pretty much required to support (or be supported
by) IE, commercial scripts are HTML DOM scripts. They requre that the
browser interpret their related documents _only_ as HTML (tag-soup or
not) and that makes it insane to author documents with XHTML-style
mark-up and then script it on assumption that it will _never_ be
interpreted as XHTML by a browser. That path just leaves people to be
confused about what they are really doing.
Agreed, but the question was with regards to referencing the hidden
input using JavaScript. Server-side processing of the form is a
different story.
Click to expand...

If the elements must have names in order to be useful then they don't
need to have IDs in order to be meaningfully referenced in the DOM.
<snip>

I would accept this if you could provide an official w3
recommendation that supports it.
Click to expand...

How would a W3C recommendation support the assertion that accessing
through the DOM specified collections is better than using -
getElementById -? That is not of relevance to what a W3C recommendation
is.

Using the collections is better because they are more widely and more
consistently supported (allowing a one-code-fits-all-browsers style of
authoring (which results in code that is cheep to create and maintain
and very reliable)), self-documenting (because the appearance of -
forms - and - elements - in the code makes it very clear what types of
elements are being referenced/used) and the resolving of the element
references is generally much faster because the references are looked up
in smaller, more specific, collections. With speed, reliability,
consistency and ease of maintenance on their side the label 'better' is
hard to dispute.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Make an <input type="text"> input-ready for input 8
Javascript DOM 1
"input-group-text" help 7
Hidden drop down 1
Move a Form action="ThatPage.php" to an <input type="??" > inline 1
[HELP] Add-on - Twitch chat input 0
Can I modify the tooltip display on an <input type="xx"> statement? 2
How to treat an input data as variable? 4

Members online

Total: 87 (members: 3, guests: 84)
Robots: 114

Forum statistics

Threads
474,002
Messages
2,570,260
Members
46,858
Latest member
FlorrieTuf

Latest Threads

Top