[whatwg] HTML 5 : Misconceptions Documented

On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
>>
>> (3) There is no specification for a special [[Get]] for the "elements"
>> HTMLCollection as a shortcut to "namedItem", either (though this would not
>> seem to be a problem,
>
> Actually, there is:
> http://www.w3.org/TR/html5/dom.html#htmlcollection
> and I believe the "elements" property of HTMLFormElement is actually
> an HTMLFormControlsCollection:
> http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
>

First off, the IndexGetter behavior on the HTMLCollection[1] is the
authors imagination. It is a shame to see such misinformation has made
it so far.

The following example shows that indexed Properties exist on
NamedNodeMap, HTMLCollection, NodeList (just like they do on Arrays).
There is no [[ IndexGetter ]] as Cameron likes to make pretend.

======================================================
<!DOCTYPE HTML>
<html>
<head>
<title>Additional Properties on NamedNodeMap, HTMLCollection, NodeList</title>
<link rel="author" title="Garrett Smith" href="mailto:dhtmlkitchen at gmail.com"/>
</head>

<body id="body">
<select id='s'>
<option></option>
</select>
<pre>
<script type="text/javascript">
var s = document.getElementById('s');
document.write([
  "NamedNodeMap: '0'in document.body.attributes : "
  + ('0'in document.body.attributes),
  "HTMLCollection '0'in document.body.childNodes : "
  + ('0'in document.body.childNodes),
  "HTMLOptionsCollection '0'in s.options : "
  + ('0'in s.options),
  "NodeList: '0'in document.getElementsByTagName('*') : "
  + ('0'in document.getElementsByTagName('*')),
  "'id'in document.body.attributes : "
  + ('id'in document.body.attributes)
].join('\n'));
</script>
</pre>

<p>
    This test is informative. It is not pass/fail. There is no public standard.
</p>
</body>
</html>
======================================================

Even if the author wrote 0 tests, simple observations should show him
just how wrong he is. I wrote about this twice on public-webapi list,
addressing Cameron McCormick with direct questions. Both messages died
with 0 replies. The second one I wrote to the public-webapi list:-

| It can be demonstrated that all of: NamedNodeMap, NodeList, and
| HTMLCollection are implemented in the top 4 browsers with extra
| numeric properties being added.

| http://html5.googlecode.com/svn/trunk/incoming/garrett-smith/noIndexGetter.html

| StyleSheetList, and CSSRuleList also have this behavior. I can't
| find an object that implements indexed properties the way you
| have documented them.

| Although the HTML DOM spec defines a 'length' property for
| NamedNodeMap, yet provides no way to access items by index. This
| seems to be a strange design decision, though not the most harmful.
| Ideally, such decisions would be tested out before writing a lengthy
| document. Firefox, Opera, Safari, and IE all allow access by ordinal
| index, via property access, but not by the way you have described in
| your document.

My example demonstrates that there is no [[ IndexGetter ]] on
NamedNodeMap, et c. Ignoring valid criticism serves no useful purpose.
This was documented in IDL, of all the places.

>> and all implementations have supported this behavior for quite a long time).
>
> Note that all implementations also supports the same behavior on
> HTMLFormElement and HTMLDocument.
>

That is not true about document. There no indexed properties, no [[
IndexGetter ]], and no [[ NameGetter ]] and no named property. There
may be either a specialized [[ IndexGetter ]] or an indexed property
on a Form Element, and the [[ IndexedGetter ]] exists only in Firefox,
on the HTMLFormElement. I cannot understand decision to specify [[
IndexGetter ]] as "standard" for all objects with indexed properties
when it has been demonstrated to exist only on HTMLFormElement and
only in one browser:

Firefox.

==========================
<!DOCTYPE HTML>
<html>
<head>
      <title>Document</title>
      <style type='text/css'>
li {
      display: none;
}
      </style>
</head>
<body id="test">

<h1>Document Has</h1>
<ul>
      <li id='nameProperty'>Named Property</li>
      <li id='noNameProperty'>No Named Property</li>
      <li id='nameGetter'> [[ NameGetter ]]</li>
      <li id='indexProperty'>Indexed Property</li>
      <li id='indexGetter'>[[IndexGetter]]</li>
      <li id='noIndexProperty'>No Indexed Property</li>
</ul>

<h1>Form Has</h1>
<ul>
      <li id='fnameProperty'>Named Property</li>
      <li id='fnoNameProperty'>No Named Property</li>
      <li id='fnameGetter'>[[ NameGetter ]]</li>
      <li id='findexProperty'>Indexed Property</li>
      <li id='findexGetter'>[[IndexGetter]]</li>
      <li id='fnoIndexProperty'>No Indexed Property</li>
</ul>

<form action="" name="f">
 <input type="text" name="t" id="t">
</form>

<script type="text/javascript">
var ids = [];
if('test' in document) ids.push('nameProperty');
else {
 ids.push('noNameProperty');
 if(document.test) ids.push("nameGetter");
}
if('0'in document) ids.push('indexProperty');
else {
      ids.push('noIndexProperty');
      if(document[0]) ids.push('indexGetter');
}

var f = document.forms[0];
if('t'in f) ids.push('fnameProperty');
else {
 ids.push('fnoNameProperty');
 if(f.t) ids.push("fnameGetter");
}if('0'in f) ids.push('findexProperty');
else {
 ids.push('fnoIndexProperty');
 if(f[0]) ids.push('findexGetter');
}

try{
for(var i = 0; i < ids.length; i++)
 document.getElementById(ids[i]).style.display = "block";
 } catch(x) { alert(ids[i]); }
</script>
</body>
</html>
==========================
Safari3, Opera9, IE8

Document Has
  No Named Property
  No Indexed Property
Form Has
  Named Property
  Indexed Property

Firefox3:
Document Has
    * No Named Property
    * No Indexed Property
Form Has
    * Named Property
    * [[IndexGetter]]
    * No Indexed Property

The results show that document has no [[ NameGetter ]] or [[
IndexGetter]], and a Form has no [[ NameGetter ]] or [[IndexGetter]],
except in Firefox, which implements some sort of specialized [[Get]]
(Cameron would call this the "[[IndexGetter]]") on the Form, and my
example uses that term.

Historically, Netscape's document object had FORM and Image named
elements' names as properties. It is unnecessary to have these
lookups, as we can easily use the DOM document.forms collection.
Creating a specification for new functionality based on a the
deprecated Netscape API is pointless because we have the "elements"
collection, and it is bad because it may introduce problems (it is in
fact specified incorrectly).

There is no point of using Netscape 4 DOM document property lookups in
HTML 5 for examples, and certainly not for a specification. This is
intellectual idiocy.

[1] HTML DOM
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/ecma-script-binding.html

Garrett

>
> --
> Thomas Broyer
>

Received on Monday, 4 August 2008 23:03:08 UTC