[whatwg] HTML 5 : Misconceptions Documented

On Wed, Aug 13, 2008 at 2:02 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 13 Aug 2008, Kristof Zelechovski wrote:
>>
>> While we are at collections and arrays, it is worth noting that the
>> {coll.length} attribute is a misnomer.  I would always ask for
>> {coll.count} when I was learning and meditate upon why it did not work.
>
> It's too late to change that kind of thing, and consistency is better at
> this point, so we should keep using 'length'.
>

of course.

However, there is the possibility of changing the WF 2.0 documentation to:
1) call the collection a collection (not an array)

2) access elements via the - form.elements - property, not treating
the form as a collection and .

In Web Forms 2.0 we have:

| If a name is used by more than one control, the
| form object has a property of that name that references
| a NodeList interface that lists the controls of that name.
|
| If a name is used by exactly one control, the form object
| has a property of that name that references that control.

This explicit standardization encourage authors to treat the form as a
collection.

That practice is a problem because it creates ambiguity with property names.

It is a fairly common mistake for a developer to use the following construct:

<input type=submit name=submit>

It is historically a problem dating back to Netscape 4.

The problem is that it would create an issue with the form's submit()
method in most browsers. 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?

What is the decision for advocating the coding practice of form-as-collection?

What is the rationale for standardizing it?

Modern browsers, for compatibility, have implemented the older
Netscape 4 functionality. Pages use this type of coding less and less.

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"?

======================================
<!DOCTYPE HTML>
<html lang="en">
<head>
<title>
 Form as Collection - submit, length, name,
  tagName and action replacement  </title>
  <meta name="flags" content="WebForms2.0" />
  <link rel="help"
href="http://www.whatwg.org/specs/web-forms/current-work/#resetFromDataDOM"/>
  <style type="text/css">
.fail {
  background: #F33;
}
#pass {
  display: none;
  background: #0f0;
}
  </style>
</head>
<body>
<form action="a" name="n">
  <input name="sub" type="radio" value="b"/>
  <input name="act" type="radio" value="c"/>
  <input name="nam" type="radio" value="d"/>
  <input name="tagName" type="radio" value="d"/>
  <input name="length" type="text" value="-1">
</form>
<div id='pass'>PASS</div>

<script type="text/javascript">
var form = document.forms[0],
  failed = false;
  form.elements.sub.name='submit';
  form.elements.act.name='action';
  form.elements.nam.name='name';

if(!form.submit.name) {
  fail('submit() was not replaced: ' + form.submit.name);
  failed = true;
}
if(form.action === "a") {
  fail('action was not replaced.');
  failed = true;
}
if(form.name === "n") {
  fail('name was not replaced.');
  failed = true;
}
if(form.tagName.value === "d") {
  fail('tagName was replaced with element: ' + form.tagName);
  failed = true;
}
if(form.length.value === "-1") {
  fail('length was replaced with element: ' + form.length);
  failed = true;
}

if(!failed)
  document.getElementById('pass').style.display
    = "inline-block";
function fail(s){
  var f = document.createElement('div');
  f.className = 'fail';
  f.appendChild(document.createTextNode('FAIL: '+ s));
  document.body.appendChild(f);
}
</script>
</body>
</html>
======================================

Results in Firefox 3, Spidermonkey, Opera 9, Safari 3, IE7:

FAIL: tagName was replaced with element: [object HTMLInputElement]
FAIL: length was replaced with element: [object HTMLInputElement]

But we can witness early adoption this specification by observing what
will happen in an older version of Safari.

FAIL: submit() was not replaced: undefined
FAIL: action was not replaced.
FAIL: name was not replaced.
FAIL: tagName was replaced with element: [object INPUT]
FAIL: length was replaced with element: [object INPUT]

While not ideal, this seems to be a more desirable result than what
Safari 3 produces. It seems undesirable (as well as a standards
conflict) to assign form.tagName an INPUT object.

Rather than give a form a corresponding property for each named
element, it seems much better design to use the elements collection
for this behavior, and the specification should encourage such use
with words and examples.

The only reason I can see standardizing this further is that browsers
implement this today and it is (I was wrong) standardized[2] (though
vaguely).

Considering the vague wording of the DOM 2 HTML Spec:
| The FORM element encompasses behavior similar
| to a collection and an element. It provides direct
| access to the contained input elements as well as
| the attributes of the form element. See the FORM
| element definition in HTML 4.0.

How much consideration went into that vague wording?

It seems like a better idea to discourage using form-as-a-collection,
even deprecate it. It is error prone and creates conflict between
specifications.

[1] Document Object Model HTML
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTML-HTMLFormElement-length
[2] Document Object Model HTML : Interface HTMLFormElement
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357

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

Received on Thursday, 14 August 2008 18:15:33 UTC