[whatwg] HTML 5 : Misconceptions Documented

[Cameron McCormack]

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 with
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 necessarily
mean that [IndexGetter] etc. will have to be changed, just that for the
purpose of documenting HTML collections they’re insufficient.

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:

  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?

> Cameron McCormick is learning JavaScript and in the process, trying to
> write a specification. That is dangerous. What is worse is that he is
> displaying complete arrogance by refusing to discuss his obvious
> mistakes based on what he and Simon imagine browsers are doing and
> what they want browsers to do. That, I pointed out, and in a fairly
> cordial manner here:
> http://lists.w3.org/Archives/Public/public-html/2008Jul/0169.html

I wouldn’t say that I know every detail of ECMA-262 off by heart, so in
that regard I’d agree that I’m learning.

And please don’t take my non-reply as arrogance.  Other things in my
life have just taken precedence the last few weeks. :-)

> But unfortunately Cameron decided to make neither change nor
> acknowledgment of this mistake of his (I will probably not have time
> or energy to get around to discussing his other mistakes, which are
> probably more serious and potentially harmful).

I have certainly tried to write Web IDL with the aim of it being useful
for other specs (like HTML 5) to document actual behaviour, where that’s
interoperable, and to that end I do test implementations.  Now in this
particular instance, I didn’t test whether the properties were real ones
or not, so thanks for that test that shows they are.

> That part of the specification was based on either misunderstanding,
> poor observation, or imagination. It has been documented vaguely,
> making references to EcmaScript [[Get]], but is apparently supposed to
> be used in other languages. Since the item() method is always
> available, it is really unnecessary and can only serve to create real
> problems by requiring the changing of Stable code.

ECMAScript 3rd ed and Java are the only language bindings included in
Web IDL, but I try to make the extended attributes generic enough to be
useful for other languages.

> Here is Cameron demonstrates his failed attempt to understand what the
> browser is doing:
> 
> http://www.w3.org/TR/DOM-Bindings/#IndexGetter
> | If the [IndexGetter]  extended attribute appears on an
> | operation with a single unsigned long argument, it indicates
> | that an object that implements the interface  can be indexed
> | with an unsigned long,
> 
> Apparently it would mean something like:
> 
> // "operation"
> childNodes[ 0 ];
> 
> I clearly nicely pointed out Cameron's misunderstanding to him, on
> this list;
>
> With the methods item() and namedItem() and getNamedItem(), the
> bindings in EcmaScript can provide property access to the property.
> There is no [[IndexGetter]].

As [IndexGetter] is written at the moment, no, but as you’ve shown,
the numeric properties do exist.  And, assuming the wording is fixed up
to say that those real properties do exist on the object, is there still
a problem with using that in an example?

> >  (i.e. '0'
> > in document.forms would be False, and document.forms["0"] wouldn't be
> > equivalent to document.forms[0])
> >
> 
> Why do you say this?
> 
> In EcmaScript, document.forms[0] is equivalent to document.forms['0'].
> I'm not sure what you're thinking.
> 
> Property access calls ToString on the property name. What would be
> "shared" with Python and Ruby?

I think Simon’s saying that something similar, i.e. indexing an object,
could be implemented in Python and Ruby.  I’m not really a Python or
Ruby programmer, but I have seen some documentation on how Python can do
that sort of thing:

  http://docs.python.org/ref/specialnames.html

So if someone were writing Python bindings for some interface written in
Web IDL, then you could consider the [IndexGetter] to be a good guide to
do that sort of thing.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/