[whatwg] Fwd: HTML 5 : Misconceptions Documented

[back to whatwg list.]


---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: 2008/8/12
Subject: Fwd: [whatwg] HTML 5 : Misconceptions Documented
To: CSS 3 W3C Group <www-style at w3.org>


2008/8/12 K?i?tof ?elechovski <giecrilj at stegny.2a.pl>:

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:dhtmlkitchen at gmail.com]
> 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
> <giecrilj at stegny.2a.pl> 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
>>
>>
>>
>>
>
>

Received on Tuesday, 12 August 2008 13:22:35 UTC