Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics

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

Received on Friday, 15 August 2008 00:53:44 UTC