[whatwg] HTML 5 : Misconceptions Documented
mjs at apple.com
Wed Aug 6 02:29:14 PDT 2008
On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:
> Hi Garrett.
> Garrett Smith:
>> 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.
> I’m sorry I haven’t had a chance to reply yet, I’ve been quite busy
> other things and haven’t had a chance to work on Web IDL for the last
> few weeks. (Actually I had a half written reply to your earlier mail
> drafted, but I hadn’t got to finishing it yet.)
> Your tests do show that the HTML collections expose items through real
> properties rather than “fake” ones returned through a custom [[Get]].
> So yes that means that HTML 5 won’t be able to use [IndexGetter]
> etc. to
> accurately describe current browser behaviour. That doesn’t
> mean that [IndexGetter] etc. will have to be changed, just that for
> purpose of documenting HTML collections they’re insufficient.
I think Garret has a valid point (despite his needlessly rude tone)
that the way we describe magical dynamic properties in a way that
makes clear they are also visible to the "in" operator and to
Object.prototype.hasOwnProperty. Are there any DOM bindings that have
index (or named) properties which are *not* visible in such a way? If
not, then the current [IndexGetter] definition is useless and we need
a better formalism.
> I think that Web IDL can’t provide as much syntactic help for HTML
> collections where the properties are real. So HTML will probably have
> to include a sentence such as:
I also don't understand what is meant to by calling some properties
"real". I don't think this is a meaningful distinction. The core of
the point that Garret raised (as far as I can tell) is that the
properties are visible to has/in checks as well as gettable, and I
think this is true in all cases of DOM objects with dynamic index/
> In the ECMAScript language binding, for every node in the collection
> there must exist a property on the collection object whose name is
> the index of the node in the collection, and whose value is the node.
> With some wording about whether these extra properties take precedence
> over other properties on the object due to the interface, etc. Ian?
I think Web IDL should provide a formalism to cater to this, because
nearly all bindings with special dynamic properties work like this
afaik. But I think it would have to involve a pseudo-method for the
"hasOwnProperty" check (which "in" is based on).
More information about the whatwg