Garrett Smith wrote:
Due to the mechanics of various implementations of the DOM, JavaScript
operators may or may not have the ECMAScript intended behavior when an host
object's 'own' property is changed (assuming the property is 'flexible').
ES3.1 isn't even done. There aren't any implementations of it. How
could a property be "flexible" ?
Ecma-262 does not have intended behavior for Host objects, does it?
These are strong indications that 'poor word choice' is not the issue
at hand, or at least not the only one. 'poor understanding of relevant
standards' is one explanation. 'Analytical mistakes' could be another.
Why do you want to know how 'delete' operator works with Host object?
It seems like a bad idea to attempt this.
WebIDL should not define how Host objects in ECMAScript work no. Nor
provide the tools for other specs to define that.
What WebIDL should do though is to define how the 'delete' operator
works when applied to various properties on objects that are exposed to
web pages though. A web author should be able to rely on what happens
when |delete document.getElementById| is called.
As Travis's code below shows, different browser behave differently in
certain situations. The point is that no spec, including ECMAScript,
fully defines what the correct behavior is.
This is a problem and needs to be remedied, unspecified behavior is
generally a bad thing.
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.
That isn't a question.
Hmm.. sounds like a question to me. I guess it doesn't end with a
question mark, but the grammar seems to indicate a question nevertheless ;)
English is a second language to me though...
To answer Travis's question: I think that WebIDL should define a default
behavior for DOM properties, yes. And if needed it should provide tools
for other specs to override that behavior on individual properties.
This is: Why does WebIDL need to define how
delete works on Document.prototype.getElementById?
This is also a question.
The answer is that web pages out there do a lot of weird things. And
many of them do them and only test the behavior in one browser. This
means that the page might not work users of other browsers. This makes
these users sad as it decreases the ability for them to use the browser
of their choosing.
This is how sad the users will be:
http://developer.mozilla.org/wiki-images/en/a/ac/Moz_ffx_openStandards_800x600.jpg
:)
There is no
guarantee that Document will be an object, or that Document.prototype
will be the [[Prototype]] of document. Nor should there be.
I can't imagine why anyone would expect to call - delete
Document.prototype.getElementById - and then complain about the
result. >
There is no guarantee by any spec where getElementById needs to exist.
For example, on Internet Explorer, document.getElementById seems to be
an own property.
javascript:alert(({}).hasOwnProperty.call(document, 'getElementById'));
IE true
(Opera 9.x will always return false for such calls on Host objects, so
cannot ever be trusted).
There doesn't seem to be a prototype chain for the document object in
IE, at least not one that includes Object.prototype. We can observe
that document does not have a valueOf method.
javascript:alert( document.valueOf )
IE: undefined
This is perfectly standards compliant and does not cause any problems.
What do you base "does not cause any problems" on?
When we implemented getElementsByClassName in firefox a lot of pages
broke. These pages were doing things like
Element.prototype.getElementsByClassName = function (s) { ... };
However due to some architectural choices in Firefox
.getElementsByClassName ends up being defined not just on
Element.prototype, but also on HTMLElement.prototype,
HTMLDivElement.prototype, HTMLInputElement.prototype, etc.
The above works fine in webkit (if i recall correctly), since it only
defines .getElementsByClassName on Element.prototype, and so can be
overridden there.
Pages working in safari but breaking in Firefox is a problem.
The effects in IE that you point out above I'm sure can cause similar
site breakage. It is therefor good if we can get it defined how this
should work in a web context so that we can get uniformity between
browsers and have sites working better.
So no-one is trying to define how Host objects in ECMAScript should
behave. We're trying to define how DOM objects behave when used from
ECMAScript.
/ Jonas
