- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 12 Aug 2008 11:02:29 -0700
(to list)
---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, Aug 12, 2008 at 11:00 AM
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
To: Kristof Zelechovski <giecrilj at stegny.2a.pl>
On Tue, Aug 12, 2008 at 4:53 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> It is probably too late for that but I like the concept of a default
> property much better than metaattributes like IndexGetter.
Browsers implement items as properties. It is safe for them to do so,
because elements shouldn't have numeric names like - 0 -.
IndexGetter, is as Maciej put it, "spec fiction".
> For example, document.forms(0) means "call forms on document with argument
> 0". That is impossible because forms is not a function so we look into
No, that is not correct. document.forms is a collection. Some browsers
allow HTMLCollection to implement [[Call]]. Some browsers may even
allow the form element to be callable as in - document.forms(0)(0) -.
It's not relevant or useful. Just a browser oddity.
> forms collection and we see that it has the default method named item. So
Whether 'item' is a method or not cannot be determined. Whether a form
has an item property can be determined. A somewhat tangential but
interesting bug: MSIE 6-8, getting the - item - property returns a
string value.
javascript:alert(document.childNodes.item === "[object]");
This is a bug, but regardless, the item property itself has no
properties, so cannot be further inspected beyond using typeof
operator.
javascript:alert(typeof document.childNodes.item);
"string" in IE.
> we proceed by expanding it to document.forms.item(0) and we see it works.
That would return the 0th form in the document, not any element in the form.
> I like it because it is simple, elegant and generic, whereas IndexGetter and
> what you have looks ad-hoc.
> I have never seen document.forms.main used to get at the form named "main"
> but probably I have not seen that much.
> I wonder how common it is.
It is fairly common.
> Of course, I agree that it is best to be explicit and not to rely on such
> tricks at all. The downside is that, for example, while
> a.getAttributeNode("href").value = url is technically superior to a.href =
> url, it is much harder to read so care must be taken not to overshoot.
Swiching gears to attributes, the attributes-as-properties is
deprecated[2]* but still heavily used because it is easier to use.
> But
> form.elements.item("main") is just fine.
It is not fine. It is non-standard and won't work across many
implementations. There is no reason to use this.
> Regarding how the named elements get to be true properties, the shadowing
> behavior can be specified without recurring to getters. It is sufficient to
> say that an intrinsic property is never replaced by a constructed shortcut
> property and we get the same result.
The term "intrinsic property" is made up.
The reason length can't be replaced is because it's readOnly. The same
should probably hold true for the "namedItem" property, though that
property is not specified to be readonly. That should change. The
namedItem property should not be read/write. I can't see any harm in
adding the readonly restriction. Code that depends on replacing the
namedItem value with something else would be unreliable in today's
browsers (and would be of questionably poor design).
Other properties like "toString" aren't standardized. In some cases,
the implementation will add proprietary properties e.g. "constructor".
In some implementations, there may be a prototype chain with other
properties that could be shadowed.
It is unlikely that a form element would have the name or id
"namedItem" but it is conceivably possible.
For example:
<!DOCTYPE HTML>
<html lang="en">
<head>
<title>namedGetter</title>
<style type="text/css">
.pass { background: #0f0; }
.fail { background: #f43; }
.warn { background: #FC5; }
</style>
</head>
<body>
<form>
<input name="namedItem" />
<input name="length"/>
<input name="toString"/>
<input name="constructor"/>
</form>
<div id="result"><li>no result</li></div>
<script type='text/javascript'>
var r = document.getElementById('result'), failed;
var f = document.forms[0];
var namedItem = f.elements.namedItem,
length = f.elements.length,
toString = f.elements.toString,
constructor = f.elements.constructor;
r.innerHTML = '';
if(namedItem.getAttribute)
warn('elements.namedItem was replaced by an element. Found: ' +
namedItem.name);
if(typeof length != "number")
fail("elements.length was not a number. Found: " + length);
if(toString.name != "toString")
fail("elements.toString was not an element. Found: " + toString);
if(constructor.name != "constructor")
fail("elements.constructor was not an element. Found: " + constructor);
if(!failed)
r.innerHTML += "<li class='pass'>PASS<\/li>";
function fail(s) {
s = "<li class='fail'>"+s+"<\/li>";
if(!failed)
failed = s;
r.innerHTML += s;
}
function warn(s) {
r.innerHTML += "<li class='warn'>"+s+"<\/li>";
}
</script>
</body>
</html>
Opera 9, IE8:
1 warning:
* elements.namedItem was replaced by an element. Found: namedItem
1 failure:
* elements.length was not a number. Found: [object HTMLInputElement]
1 failure:
Firefox 3, Webkit nightly (525)
* elements.constructor was not an element. Found: function Object() {
[native code] }
The warning "elements.namedItem was replaced by an element." is not a
spec violation; it is perfectly standards compliant. I don't see harm
in changing the spec to make namedItem readonly.
An implementation optionally could provide, for HTMLCollection (or
whatever the new interface is called in HTML5), a specialized
algorithm for "[[Get]]" that delegates to namedItem. This wouldn't
matter either way. Fx does provide a special get that delegates to
namedItem, and does not add named properties to the form. I don't see
any problem with this.
As for property access delegating to item, the properties should
probably exist on the object. That is what implementations today do.
Defining a new behavior for typechecking on property access operator [
] would be complicated and confusing. Such change might introduce bugs
in implementations. and would create bugs in webapps that attempt to
use node.childNodes['0']. The other way to implement [indexGetter]
would be to Have HTMLCollection's special [[Get]] try to parse the
string value. This would introduce awkward complications and require
too many implementation details to be specified in web-idl.
Not everything needs to be or should be standardized.
Garrett
[2] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-1958798402
* Top posts are destroying the thread flow. I included linked
reference(s) incremented from the last number.
> Chris
>
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith
> Sent: Wednesday, August 06, 2008 8:49 AM
> To: Thomas Broyer
> Cc: whatwg at whatwg.org
> Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
>
> On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer <t.broyer at gmail.com> wrote:
>> On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
>>> On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
>>>>
>>> First off, the IndexGetter behavior on the HTMLCollection[1] is the
>>> authors imagination.
>>
>> Aren't "document.forms[0]" and "document.forms.myform" working?
>>
>
> Can you be more specific and direct in your reply? It isn't clear what
> your point is.
>
>>> 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.
>>
>> This is an "implementation detail" of the ECMAScript binding.
>>
>
> In EcmaScript, the property access operators seem to look like a
> "getter" to Cameron. What they really do is provide access to
> properties added to the collection, or, in one case (on one
> implementation), this seems implemented as a "getter". A "getter" is a
> method that gets the value of a property of that name.
>
>
>
>
Received on Tuesday, 12 August 2008 11:02:29 UTC