[whatwg] HTML 5 : Misconceptions Documented

Sun Nov 23 16:15:33 PST 2008

On Mon, Nov 10, 2008 at 12:56 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 14 Aug 2008, Garrett Smith wrote:
>>
>> There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the
>> HTML DOM specifications that an element should not be named "submit" or
>> "action" to avoid such consequences. Was this considered?
>
> I don't think we want to limit these names, since this would be an
> unbounded set of names that made older documents non-conforming as the
> language evolved.
>
>
>> What is the decision for advocating the coding practice of
>> form-as-collection?
>
> It's convenient.
>

It is an ill-advised practice that has been known to be a source of problems.

http://www.jibbering.com/faq/faq_notes/form_access.html#faComMis

>
>> What is the rationale for standardizing it?
>
> Browsers support it.
>

They don't really do a very good job of supporting it in a way that is
reliably useful.

We can see that if a control is name "item", for example, the form
will, in Opera, end up with an item key that ends up in the loop
twice:-

<!DOCTYPE HTML>
<html lang="en">
<head>
   <title>length twice</title>
</head>
<body>
<form action="javascript:;" id="form1">
        <input name="length" type="text"/>
</form>
<script type="text/javascript">
var f = document.forms[0].elements, a=[];
for(p in f) {
   a.push('"'+p+'" : ' + f[p]);
}

document.write("<xmp>"+a.join(",\n")+"<"+"/xmp>");
</script>
</body>
</html>

Opera:
"0" : [object HTMLInputElement],
"length" : [object HTMLInputElement],
"length" : [object HTMLInputElement],
"item" : function item() { [native code] },
"namedItem" : function namedItem() { [native code] },
"tags" : function tags() { [native code] }

We can also see that there is a memory leak created in Firefox and
Webkit when accessing form controls directly off the form.
http://jibbering.com/faq/names/simple-leak-form-input.html

It is advisable to not use form as a collection. It provides no added
convenience. It provides safety. Also, it is defined.

If WF 2.0 is going to define form to be a collection, it should do so
in a way that is clear an unambiguous. One way to do this would be to
clearly define the collection type, e.g. "The HTMLFormElement extends
the HTMLFormControls collection". However, it should be the case that
this is true in the majority of desktop browsers. Currently, it is
not; accessing controls directly from the form works a little
differently.

WF 2.0 should also define conflict resolution between properties of
the form (which may be readonly) and getters, which may be present ont
the form's prototype chain (this is legal and implementation
dependent).

>
>> The implied expectation of the specification is that the values for
>> form.action and form.submit will be replaced by elements of the
>> corresponding name. It could be expected that an element named "length"
>> or "tagName" would create a "length" property on the form, except for
>> the fact that form.length is defined as readonly[1] in another
>> specification. What should happen in that case? Can a readonly property
>> be replaced? What is the suggested approach for submitting to an API
>> that requires a parameter named "submit" or "action"?
>
> WebIDL will define these cases.

It seems that your Web Forms API specification has already done so:
http://www.whatwg.org/specs/web-forms/current-work/#additions

- and we can witness yet again an early adoption in Webkit.

http://jibbering.com/faq/names/form_override_change_name.html

Safari 2 result:
FAIL: The following 80 form properties should have been an INPUT element:

Safari 3 result:
PASS - All Form Properties Replaced by an Element

We can clearly see that Safari 3 is more compliant to the API than
Safari 2, and without any WEB IDL to describe what should happen when
replacing readonly properties or setting value to a property that has
a getter in the prototype chain.

It would be a good idea to not use examples which directly access
controls off the form in non-standard fashion. I also recommend that
the relevant sections of Web Forms 2.0 be removed. At the very least,
the relevant sections should be amended with a note describing that
the problem has not yet been resolved.

Also, you should change "elements array" so that it is not called an
array. Calling the elements collection an array will only add to the
misconception.

Garrett

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