Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.mixmin.net!news2.arglkargh.de!noris.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <3859479.tbURmrfCUx@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 29 Sep 2012 22:17:33 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 129 NNTP-Posting-Date: 29 Sep 2012 22:17:34 CEST NNTP-Posting-Host: 34ac3510.newsspool1.arcor-online.net X-Trace: DXC=A0 Gaaah Feel better. > I'm fairly certain there's a reason that I think this is a "bad" idea ... > apart from anything else an element name parameter is not guaranteed to > be unique within a document - "Parameter"? > but I haven't easily been able to find a suitable reference for why not to > do this, anyone got one? > > I'm arguing to replace using document.formname to identify forms with > assigning an id to the forms involved and using document.getElementById > ("formid").*, but the best arguments I can think of at the moment (more > robust to future changes, better compatibility with developing standards, > more maintainable) are butting up against "don't fix it until it needs > fixing", whereas I prefer to prevent future breakage, rather than react > to it. The two are not semantically equivalent to begin with. > I'm pretty certain that using document.getElementById("id") is better > than using document.elementname, but at the moment I'm having trouble > pointing to any sort of authoritative reference for this. One is standards-compliant [DOM2Core]/[DOM3Core]; the other is not [DOM0]. One is accessing the ID namespace, the other one is accessing the id+name namespace [SO], and a property of the object referred to by `document'. That object has properties that are not holding a reference to a form element object. Insofar the latter referencing is not only proprietary, it is also more error-prone. > [1] It was document.all.formname which was breaking, a very senior coder > (but not actually a web / js coder) "fixed" it by changing > document.all.formname to document.formname, but I think the fix is almost > as prone to future breakage as the original code was, and would prefer to > see document.getElementById("formid") used instead, with approriate IDs > allocated to forms. They should have replaced it at least with document.forms["formname"] as specified in [DOM2HTML], [HTML5WD], [HTML5ED], and [WHATWG-HTML]. This would work both with names and IDs, with names being the most backwards- compatible approach (down to [DOM0] as introduced with Netscape Navigator 3.0 and Internet Explorer 3.0 [DOM2HTMLGloss]). However, if there were two forms with the same name (valid) or same ID (invalid) in the document, the property value would (likely) be a NodeList of Elements, contradicting [DOM2HTML], and the first item with that name of a HTMLCollection per [HTML5WD], [HTML5ED] and [WHATWG-HTML] as defined in [DOM4] §8.2 and [WHATWG-DOM] §8.2, respectively¹. PointedEars ___________ ¹ It is actually *unspecified* in [DOM2HTML] what the namedItem() method of objects implementing the HTMLCollection interface is to return if there is more than one item with a matching `name' attribute. Given that the return value is specified in [DOM2HTML] to be "*The* Node with a name or id attribute whose value corresponds to the specified string. Upon failure (e.g., no node with this name exists), returns null.", the [DOM4]/[WHATWG-DOM] clarification was probably intended from the beginning. However, AFAIK it is implemented *differently* *everywhere* (from a NodeList to a HTMLCollection return value), even in browsers that claim to implement "HTML 5" (and whose vendors are represented in either the W3C WGs, or the WHATWG, or both). Which will probably need to be fixed in the specifications instead of in the implementations, as following [DOM0] there are plenty of forms out there that have controls with the same name (for example, to make an array with the `[]' prefix in PHP), use client-side scripting to access them (e. g., for form validation), and would break otherwise. References: [SO] [DOM2Core] [DOM3Core] [HTML4] [DOM2HTMLGloss] [DOM2HTML] [HTML5WD] [HTML5ED] (Editor's Draft 2012-09-28) [WHATWG-HTML] (Living Standard 2012-09-28) [DOM4] (Editor's Draft 2012-07-07) [WHATWG-DOM] (Living Standard 2012-09-27) [DOM0] (Netscape) Client-side JavaScript 1.3 Reference (archived) -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, (2004)