[whatwg] HTML 5 : Misconceptions Documented

(back on list)

On Wed, Jan 14, 2009 at 2:04 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 13 Jan 2009, Garrett Smith wrote:
>> On Tue, Jan 13, 2009 at 6:41 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >
>> > There were a number of e-mails on this thread regarding how Collections
>>
>> Which thread are referring to?
>
> The one entitled "HTML 5 : Misconceptions Documented".
>

Sorry.

>
>> > and other interfaces worked with respect to properties being exposed.
>> > I have now updated the HTML5 spec to take into account the new
>> > features in WebIDL that expose these properties. Please let me know if
>> > I missed one.
>>

I see. It looks like you've mimicked current methods of HTMLCollection
- item - and - namedItem - on the form. These methods delegate to
same-named methods on the elements collection.

I see several paragraphs that describe how HTMLFormElement has
same-named methods that delegate to HTMLCollection.

http://www.whatwg.org/specs/web-apps/current-work/#htmlformelement

The specification does not say that HTMLFormElement implement HTMLCollection.

The spec has defined new behavior, "past names map":-

| Each form element has a mapping of names to elements called the
| *past names map*. It is used to persist names of controls even when
| they change names.

If I understand this correctly, given a FORM with an INPUT named 'b',
if I change the name of that INPUT to 'a', then form.b should return
the element with name="a".

That isn't how it works in Firefox, Opera, or Safari. Here is an
example of changing a control's name. The changed control does not
remain as property on the form.

<!doctype html>
<html lang="en">
<head>
	<title>Change Control Name</title>
</head>
<body>
<form action="">
<input name='b' id="x"/>
</form>
<script type="text/javascript">
document.getElementById('x').name = "a";
document.write("(document.forms[0].b === undefined) " +
    (document.forms[0].b === undefined )+ ".");
</script>
</body>
</html>

Result:-
(document.forms[0].b === undefined) true.

If the  |b| element were in the form's 'past names map', shouldn't the
result indicate document.forms[0].b as an object?

What is the reason for introducing the "past names map" behavior to the form?

>> | The elements collection is also mirrored on the HTMLFormElement object.
>> | The length DOM attribute must return the number of nodes represented by
>> | the elements collection. The indices of the supported indexed properties at
>> | any instant are the indicies supported by the object returned by the elements
>> | attribute at that instant. The names of the supported named properties at any
>> | instant are the names supported by the object returned by the elements
>> | attribute at that instant.
>>
>> It sounds as if an HTMLFormElement is a collection, minus the
>> 'namedItem' and 'item' methods.
>
> Not even minus namedItem and item, in fact, it has those methods too.
>

Is HTMLFormElement a collection? If so, what collection?

>
>> It would be a good idea to mention the implications and side effects.
>> I would propose an example:-
>>
>> <form name="testForm">
>>   <input name="submit">
>> </form>
>>
>> document.forms.testForm.submit();
>>
>> - and explain what should happen. It would also be a good idea to
>> mention the implication for implementors.
>
> My plan is to add examples in late Q2 early Q3. If I don't include this
> example at that point (and assuming you still think it would be useful
> given the other examples that will be added) please remind me.
>
>
>> There are problems with referencing a control directly off the form:-
>>   1) controls may be returned out of order
>>   2) after a control is removed, it may still exist as a property of the form
>>
>> If the specification is going to define a collection, it should be clear
>> how the collection works. If the collection is to work exactly as an
>> HTMLCollection, then the specification should say so. Current
>> implementations are buggy with referencing a form control directly from
>> the form.
>
> As far as I can tell, the spec is exactly defined now. Is there anything
> left ambiguous?
>

The spec does not say that HTMLFormElement is an HTMLCollection (or
HTMLFormControlsCollection); it defines delegating behavior in a very
non-DRY way.

In current implementations such as Firefox, Webkit, Opera,
HTMLFormElement is not an HTMLCollection.

It sounds like you want that to change so that HTMLFormElement *is* an
HTMLFormControlsCollection.

Is this what you are proposing? If so, why?

The only benefit that was mentioned was convenience, as in:
var elements = document.forms.myForm;
elements.firstName.value = "Ian";

- instead of -

var elements = document.forms.myForm.elements;
elements.firstName.value = "Ian";

Now that may be a little less typing, but not much. I don't find it
much more convenient to reference controls directly from the form.


Making HTMLFormElement implement HTMLFormControlsCollection would be a
big change to HTMLFormElement. Surely there has got to be something
more than typing convenience to justify such change.

It seems more justifiable to advocate that authors not do that,
perhaps providing an example in an appendix of nonstandard behavior.

Garrett

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Thursday, 15 January 2009 11:27:26 UTC