Re: hidden input type and the dom

y2ee.asdf@xxxxxxxxx wrote:
<snip>

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

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).

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

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.

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.

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.

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

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.

> Then you may reference is as follows:

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

<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.

<snip>

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

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.

.

Relevant Pages

  • Re: FAQ Topic - How do I POST a form to a new window? (2011-01-03)
    ... user-defined DTD) declaring the Transitional variant of HTML 4.01 and ... XHTML 1.0 DTDs. ... HTML* requires that. ... have been tested in at most one browser. ...
    (comp.lang.javascript)
  • Re: Web Layout
    ... There is absolutely no advantage to using XHTML over HTML, and it will certainly not help in this instance. ... You need to serve valid and compliant HTML and CSS to the browser, and in 99% of cases, you will not have problems. ... It is certain that Opera and FF are correctly rendering the code, and that IE is doing its best to make sense out of invalid code. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: The XHTML Factor
    ... Well, XHTML 1.0 has nothing more to offer than HTML 4.01 has, it has ... And indeed the browser with the most market share, MS Internet Explorer, ... deliberate nesting error, and the other iframe containing exactly the ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Form spam? What to do?
    ... >> now serving many new pages in true xhtml 1.1 using the correct mime ... > Your script will serve application/xhtml+xml to a browser with an Accept ... On contrast IE6 accepts the html 4.01 strict code as you can ...
    (alt.html)
  • Re: XHTML Problems
    ... to know whether it's HTML, XHTML, a flat file or dynamically generated, ... ..html suffixed link. ... There's one link, and the server provides what's needed, behind the scenes. ... their browser and my server can ...
    (comp.infosystems.www.authoring.html)