[back to whatwg list.]
---------- Forwarded message ---------- From: Garrett Smith <[EMAIL PROTECTED]> Date: 2008/8/12 Subject: Fwd: [whatwg] HTML 5 : Misconceptions Documented To: CSS 3 W3C Group <[EMAIL PROTECTED]> 2008/8/12 Křištof Želechovski <[EMAIL PROTECTED]>: Another top post. > Reading the specification does not help; the trick is described in a note in > appendix D of what? > which I have not read because it is hardly necessary (otherwise > it would not have been a note in an appendix). It mentions 'coll["$name"]' > but not 'coll.$name'. I understand the notations are equivalent under > JavaScript; however, 'coll["$name"]' makes no sense in Visual Basic but > 'coll.$name' is still supported (surprise!). The construct 'coll("$name")' > must be necessarily equivalent to 'coll.item("$name")' because only one > property can be the default; that is why overloading collection.item is > necessary. An HTMLCollection is not standardized to be a callable object, e.g. so coll('$name') can't be expected to work and will not work in a few compliant implementations. Firefox, for one, doesn't make a collection callable. OTOH, if a collection is callable, it means that it should probably return "function" for typeof. EcmaScript typeof operator should result in "function" when used with a native callable object. An HTMLCollection is a "Host" object. When used with a Host object typeof may legally return anything. Although IE's implementation might seem against the intent of the spec by returning "object" for callable host objects, it is a legal behavior. > Neither specification contains an argument that it is not ridiculous to have > form.length mirror form.elements.length. The need for form.length dates > back to Netscape DOM because the collection form.elements was not there, I > guess. You are just wasting my time. I don't think there's any disagreement that form.length is redundant. But like it or not, form.length is part of that DOM 1 spec I linked to. If it were to be removed from the spec, it might break sites. It could potentially be deprecated in HTML5 and removed in a future version of HTML. > Your original post criticized the code sample provided because the > constructs used there were ambiguous. The original post pointed out three problems: 1) Treating a form element as an HTMLCollection. 2) The use of - with - to augment the scope chain is not necessary. 3) Calling the "elements" HTMLCollection an "array #1 has been discussed a lot. There is evidence that treating a form element as an HTMLCollection is non-standard, but not yet a strong consensus that this practice is bad and should be discouraged. I think more solid examples and reasoning is needed on why it is bad. #2 got some agreement #3 did not get debated at all. Clearly, HTMLCollection is not an array. This is a pretty serious mistake. It is the misconception that I first had in mind. This should have been changed two weeks ago, soon after it was pointed out to Ian. HTML 5 should not propagate misinformation. [regarding form.lenth vs form.elements.length: ] > They may be ambiguous to a casual > reader but the host can, in theory, interpret them unambiguously and > consistently. I admit Internet Explorer does it all wrong though. I am > disappointed. IE and Opera seem to replace the HTMLCollection's length property's value. It is also possible that they have another unobservable internal mechanism that makes this appear so. Either way, the result is a bug when elements.length or form.length results in an object (a collection of form controls). In IE and Opera, the length property can return an object. This is a non-standard spec violation. Replacing the 'namedItem' property is perfectly standards compliant. The standard should probably change to make the 'namedItem' property readonly. Having these extra properties also exist on an HTMLFormElement is unnecessary. It complicates matters because a form element has other DOM properties, such those from Node, et c. It would create the problem of trying to refer to an element:- /** Error prone */ getAnElement(form, controlName) { return form[controlName]; } getAnElement(document.forms[0], "parentNode"); getAnElement(document.forms[0], "addEventListener"); Look at the Node interface, Element interface, EventTarget interface, and any other interface that the HTMLFormElement might likely implement and see that there are many properties that could potentially create conflict. It is not only redundant, but it is error prone to have such properties on the form element. Form control names as form object properties creates pollution and makes resolving properties more difficult. It is error prone: * For implementations, because it requires a more complicated algorithm. * For page authors, who cannot expect form controls to become DOM properties of the form object (because it is possible that a property of the form already exists). It is not reasonable to expect that implementations will support special getters because only one implementation has been observed to exhibit that type of behavior (Firefox). Such a getter would be subject to the same sort of conflict resolution. Garrett > Yours sincerely > Chris > > -----Original Message----- > From: Garrett Smith [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 12, 2008 7:03 PM > To: Kristof Zelechovski > Subject: Re: [whatwg] HTML 5 : Misconceptions Documented > > On Tue, Aug 12, 2008 at 9:43 AM, Kristof Zelechovski > <[EMAIL PROTECTED]> wrote: >> While 'form.elements' is not obsolete, 'form.elements.something' (to mean >> 'form.elements.namedItem("something")') is. Actually, it is some news to > me >> that such syntax is supported; I was only aware of the syntax >> 'form.something' (obsolete, but convenient) and >> 'form.elements("something")'. > > You really ought to read the specs; I've posted numerous links in this > thread.. > >> That 'form.length' mirrors >> 'form.elements.length', while still supported, is just ridiculous; I > missed > > Read the HTML DOM 1 and 2 specs. > >> that as well. Everything you say is true, except that the merrie olde >> syntaxe is not that ambiguous as you present it. Indeed, I cannot see any >> ambiguity at all. > > What ambiguity? > >> I am not using MSDN as the source of information what the Web should look >> like; I am using it to understand existing code that the standard does not >> cover, e.g. 'form.control' or 'new Image()' (incidentally, this is >> 'Image.Create()' in Visual Basic Scripting Edition). >> Thanks for pointing that out. >> Chris >> >> >> >> > >