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

On Wed, Aug 13, 2008 at 11:12 AM, Travis Leithead
<travil@windows.microsoft.com> wrote:
> I appreciate a little friendly competition and bantering,

Who are you competing with?

> but I don't think it's appropriate or in the best interest of cooperation for such personal feelings of animosity to be disclosed in such a public forum. Having written that, I would like to clarify my poor choice of imprecise language and restate my question:
>

It might be a consideration to call it 'poor word choice', but then:

> 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.

>The following code demonstrates the difference between implementations of the latest WebKit and Opera9.5. Note this is for "functions", as I am unsure if "data" and/or "accessor" properties are supposed to be defined on prototypes in the DOM (seems like they should be, but I can't remember if WebIDL allows them there or not).
>

I'm going to explain what your code does with comments annotated (GS).

You haven't stated the expected result of calling test().

What did you think test should do? How does 'test' demonstrate a
problem or supports your argument? (what is your argument?)

You make some very poor assumptions in the code below.

>  function test()
>  {

// (GS) This will result in a ReferenceError if document is
// undefined, and an alert if document is false-ish. This branch
// of code will not be executed in any of IE, FF, Webkit, Op.
>      if (!Document)
>      {
>        alert("test cannot be performed on this implementation");
>        return;
>      }

// (GS) Should not make assumption that since Document
// exists, it will have a prototype property.
>      if (!Document.prototype.hasOwnProperty('getElementById'))
>      {
>        alert("property not defined at this level");
>        return;
>      }

// (GS) Defining a getElementById property of the Document
// object's prototype and assign function value.
// "Overright" is fictitious terminology, but apparently, to you,
// "Overright" means "replace value".

>      // Overright the property:
>      Document.prototype.getElementById = function(x) { return "test"; };

// Call document.getElementById to see if the method on
// Document.prototype is called.
>      // Ensure the override was successful:
>      if (document.getElementById('foo') != "test")
>      {
>        alert("override failed");
>        return;
>      }

// delete the property defined.
>      // Try to delete it
>      try { delete Document.prototype.getElementById; }
>      catch(e) { alert("delete operator failed"); }
>      // Check to see if it was deleted...
>      if (Document.prototype.getElementById)
>      {
>         if (document.getElementById('foo') == "test")
>           alert("delete failed to remove the override");
>         else

// (GS) getElementById is not a built-in method.
>           alert("delete failed to remove the built-in method");
>      }
>      else

// (GS) Wrong. EcmaScript does not define how delete
// works on a host object.
>        alert("property was deleted (per ECMAScript rules)");
>    }
>
> Since Firefox 3 implements getElementById on "HTMLDocument" (DOM L1/HTML) instead of "Document"

> (DOM L2/Core) you'll have to replace all instances of "Document" with "HTMLDocument" to run the test on that browser.
>
> As this code shows, delete works per ECMAScript in Opera, but not in Safari or in FF3.
>

How do you arrive at the conclusion? You used the delete operator with
a Host object. Ecma-262 r3 doesn't define that.

Your code attempts to delete a property on Document.prototype. From
this, it seems you assume that if delete throws an error, it means the
property is non-deletable and if delete does not throw an error, the
property must be deleted.

Checking the return value of delete would probably be the first thing
to do, and would be one test in and of itself.

javascript:alert(delete Document.prototype.getElementById)

Webkit: false

This indicates that Document.prototype.getElementById exists and can't
be deleted. It probably has the [[DontDelete]] attribute and this
would be perfectly valid. It does not mean that the delete operator
doesn't work.

> 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. 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.

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.
Nor does the following cause problems:

javascript:alert( document.valueOf() == document );
javascript:alert( 'constructor ' in document);

The results don't really matter.

Here are some rough guidelines that may help your testing approach:
http://www.w3.org/Style/CSS/Test/guidelines.html

Garrett

> -----Original Message-----
> From: Garrett Smith [mailto:dhtmlkitchen@gmail.com]
> Sent: Tuesday, August 12, 2008 11:20 PM
> To: Travis Leithead
> Cc: Web Applications Working Group WG; cam@mcc.id.au; Allen Wirfs-Brock; Pratap Lakshman (VJ#SDK)
> Subject: Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
>
> On Tue, Aug 12, 2008 at 8:31 AM, Travis Leithead
> <travil@windows.microsoft.com> wrote:
>>
>> Cameron,
>>
>> I recently became aware of Microsoft's involvement in the ECMAScript 3.1 effort as of
>
> Surprises everywhere.
>
> about a month ago. (Including Allen & Pratap from MS Jscript, who are
> driving that effort.) ES3.1 makes a few subtle changes that I thought
> you'd like to follow up on, since they impact the WebIDL spec, namely
> "DontDelete" is changing to "Flexible", among other things which
> should be noted in WebIDL.
>
> WebIDL really needs help.
>
>>
>> I've also done some recent investigation on how browsers handle ECMAScript's operators (delete, new, instanceof, etc.) and found that they are somewhat diverging in implementation; in particular the 'delete' operator. I've noted that some implementations use the delete operator in the DOM in the same spirit that it is speced in ECMAScript--that is the delete operator removes a given property completely. I've noted that other implementations only allow the delete operator to remove a "shadowed" property on the DOM, but never actual delete the underlying "built-in" property.
>
> There is so much wrong with that statement I don't know where to
> start. You have demonstrated what appears to be a gross
> misunderstanding of the specs combined with some fictitious
> terminology to describe a phenomenon that I think you are imagining.
>
> DOM objects are Host objects. They don't have "built in" properties.
> What does underlying mean? Does underlying mean something up the
> prototype chain (implementations that have that)? Properties that
> exist in the prototype chain are called "properties that exist in the
> prototype chain." If a property exists in more than one place in the
> prototype chain, the furthest ancestor property are often said to be
> 'shadowed'.
>
> [[Delete]] does not work up the prototype chain. Your claim:-
>
> | other implementations only allow the delete operator
> | to remove a "shadowed" property on the DOM
>
> is something that I have not ever observed and something that I would
> find highly unlikely. It would require a special form of [[Delete]]
> for a Host object, and one that would seem to require extra effort to
> make the delete operator work in a very unintuitive way.
>
> I would like to see your observations. Please post your test code.
>
>> I wondered if WebIDL makes any mention of the behavior of ECMAScript operators on host objects and how they should behave?
>
> You could read it if you wanted to, and, having read it myself, I
> could answer your question. However, I would not recommend anyone who
> is not an expert to read that, and so I would not encourage you to.
> The reason I would not recommend anyone who is not an expert in the
> relevant standards to read Web IDL is that it has too much
> misinformation and bad ideas that came from someone who is almost as
> green as you. Such an official academic looking paper would likely
> have an influence on someone who is not an expert.
>
> This type of documentation is harmful for the web. It is potentially
> even more harmful for people like you who are not only green, but also
> in a position to make decisions about standards and apparently, IE. I
> would rather recommend reading
>
> the DOM TRs:
> http://www.w3.org/DOM/DOMTR
>
> the Ecma-262 spec
> http://www.ecma-international.org/publications/standards/Ecma-262.htm
>
> (unofficially available for casual reading in HTML)
> http://bclary.com/2004/11/07/
>
> I think it would be a good idea to have three solid web applications
> under your belt before continuing.
>
> If you're interested in making IE to be less of an abominable peice of
> junk, it would well behoove you to learn about browsers, the web, and
> especially the relevant standards.
>
> Garrett
>>
>>
>> - Travis Leithead - OM Program Manager - Internet Explorer
>
>pe

Received on Thursday, 14 August 2008 20:49:35 UTC