[whatwg] HTML 5 : Misconceptions Documented
dhtmlkitchen at gmail.com
Tue Aug 12 09:04:02 PDT 2008
On Mon, Aug 11, 2008 at 2:53 PM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> I have considered inline response. I have two options: do it by hand (I am
> rather busy) and do it for every reply (which makes business people angry).
The audience for this list is developers.
> I am sorry for the inconvenience it causes.
It adds more confusion to the misinformation and wrong arguments. It
makes communication more difficult and makes whatever you are trying
to argue seem harder to get the point of. It makes the discussion
harder to follow.
> The item method on a collection when the argument passed is a string that
> cannot be coerced to an integer is equivalent to namedItem.
MSDN is not a reference for web standards information. Thank you for
pointing that out.
> A form element
> does not have an intrinsic length property; it can be added as an embedded
> named control or by a script. The elements collection has the intrinsic
> length property and it cannot be shadowed.
It would be more correct to say: elements.length is readonly.
> My source of information is MSDN, as you have correctly guessed.
I didn't actually guess.
> If you
> have contradictory information on legacy interfaces, please share it with
> us. Note that there is no way we can say it is correct or not; it is an
> obsolete interface after all.
the 'elements' property of an HTMLFormElement is not obsolete
An HTMLFormElement, is not an HTMLCollection. elements is an
HTMLCollection. The form has no item() no namedItem(). These are
operations that can be carried out on an HTMLCollection.
> However, if it is consistent and all major
> implementations support it, there is no reason to think it is false.
> The name 'ell' I used is a name of an embedded control in order to make it
> different. I am not sure about undefined versus null; I rather use Visual
> Basic Scripting Edition and I get Nothing (not Empty) for a property an
Undefined is the return value from [[Get]] when a property does not
exist. It seems reasonable to expect that [[Get]] on a Host object
would behave in the same way.
> See also <http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx>.
That is useful, but should not be a reference as to how the item()
method works or should be expected to work. It is a proprietary
extension that Microsoft took. It isn't something that script authors
rely on because it's not cross browser.
 DOM Level 2 HTML http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357
> -----Original Message-----
> From: Garrett Smith [mailto:dhtmlkitchen at gmail.com]
> Sent: Monday, August 11, 2008 10:37 PM
> To: Kristof Zelechovski
> Cc: WHATWG List; Maciej Stachowiak
> Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
> On 8/11/08, Kristof Zelechovski <giecrilj at stegny.2a.pl> wrote:
> Hi Chris,
> Thanks for taking the time to respond to some things I was writing
> about. I think these are important things that deserve attention, too.
> If it's not too much to ask, have you considered inline style response?
> I tried to restore posting order, but since you are using Outlook, it
> was not effectively possible.
>> Neither the expression 'form.elements.$name' nor its expanded form
>> 'form.elements["$name"]' is supposed to be defined even if $name is an
>> identifier of an embedded control. The correct way to address the
>> is 'form.elements("$name")',
> Can you cite a reference for this?
> AFAIK, this is an IE feature that was copied.
>> which is a shorthand notation for
> No, that is wrong. Doubly wrong, I think. The item method retrieves a
> node by ordinal index (based on depth-first traversal).
> now if you had wrote:-
> That would at least be partially correct. If namedItem is what you
> meant, then please supply a reference to back up your claim. I do not
> think the claim:
> | The correct way to address the control is 'form.elements("$name")'
> is true and correct. I think it's an MSIE invention that other
> implementations copied.
>> These two should not be confused.
>> Therefore, the bug in Opera is not about shadowing the length property
>> about defining the corresponding property at all (in particular,
>> 'form.elements.ell' should be null no matter what).
> Are you referring to the example I supplied?
>> This could potentially be described in the EcmaScript bindings. But it
>> would be a good idea to explore some edge cases. Particularly, if the
>> case was the order of definition of properties: One such case would be
>> an HTMLCollection with an element named "length". In that case, the
>> readonly "length" property would have to be the actual length of the
>> collection; the value should not be replaced with an element of that
>> <form><input name="length"></form>
>> Opera9: [object HTMLInputElement] <-- BUG
>> FF3: 1
>> Saf3: 1
> There was no element in my example with a id or name 'ell', so I would
> have to say that form.elements.ell would be undefined, not null.
> Where is this - ell - coming from?
>> OTOH, the expression 'form.length' is a perfect equivalent for
>> 'form.elements("length")', provided a control with such a name is
> form.elements has a readonly property named length.
> That property can't be changed (legally) just because a parse event
> found an element named (or id'd) "length".
> The length property of a form - form.length - refers to:
>> Have you reported this to Opera technical support?
>> I can see no harm in principle in assigning a value to 'form.length'
>> length is not an intrinsic property the form object.
> Chris, I have stated at least twice prior to this email that an
> HTMLCollection has a readonly length property.
> | length of type unsigned long, readonly
> | This attribute specifies the length or size of the list.
More information about the whatwg