On Thu, Aug 14, 2008 at 4:59 PM, Cameron McCormack <[EMAIL PROTECTED]> wrote:
>
> Hi Garrett.
>
I missed a couple of points in my last mail.
> Travis Leithead:
>> > My question, once again, is whether WebIDL will define exactly how
>> > to translate the behavior of operators like delete into the
>> > JavaScript language binding for DOM objects.
>
> Garrett Smith:
>> That isn't a question. This is: Why does WebIDL need to define how
>> delete works on Document.prototype.getElementById? There is no
>> guarantee that Document will be an object, or that Document.prototype
>> will be the [[Prototype]] of document. Nor should there be.
>
> Web IDL wouldn't specifically say "delete works on
> Document.prototype.getElementById", but I think it should say how these
> kinds of objects (Document, Document's [[Prototype]]) behave, e.g.
> "a property on an interface prototype object that corresponds to an IDL
> operation has attributes { DontEnum }".
Document's [[Prototype]] would usually be Function or Object,
depending on the browser. Either way, it wouldn't really matter. If
you think it does matter, please explain how. Are you confusing
Document's [[Prototype]] with the Document.prototype property, BTW?
Regardless, it shouldn't matter to anyone.
> JS libraries do exploit the
> prototype chain to add methods etc.,
Are you talking about Prototype? They're somewhat inclined towards
changing that. There have been a lot of problems with that.
> so it would be good if they could
> do this with the blessing of a spec, rather than de factor behaviour.
Standardizing this behavior would only encourage them. It is a
horrible way to design an API. The fact that it doesn't work doesn't
mean it needs standardizing. The approach itself is inherently bad.
> Given MS's interest in following Web IDL,
Why would Microsoft be concerned with that?
There are thousands of bugs in IE that are important and critical. I
see MS priorities are: "Disabled OPTION" - closed by design.
"Implement DontEnum" - WONTFIX. And WebIDL - worth following.
WebIDL is extends the boundaries of defining interface to address
browser incompatibility issues that do not help solve real problems.
It tries to specify more detail than is necessary for "Interface
Definition Language."
> there's a chance we could get
> all four browsers doing the same thing, too.
All four browsers. You must mean Netfront, Obigo, iCab, and Opera.
All four of these browsers doing the same thing might seem like a good
idea (in a fuzzy way), however doing "what" same thing are we talking
about? That would be the determining factor. If that thing were
beneficial or harmful.
Or we could stick with interface definitions.
Garrett
> --
> Cameron McCormack ≝ http://mcc.id.au/
>
>
