W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

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

From: Travis Leithead <travil@windows.microsoft.com>
Date: Wed, 13 Aug 2008 11:12:28 -0700
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>, "cam@mcc.id.au" <cam@mcc.id.au>, Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>, "Pratap Lakshman (VJ#SDK)" <pratapl@microsoft.com>
Message-ID: <0003CB8B8FE2154EB50431DB2B8F69C00EB13034CF@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

I appreciate a little friendly competition and bantering, 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:

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

  function test()
  {
      if (!Document)
      {
        alert("test cannot be performed on this implementation");
        return;
      }
      if (!Document.prototype.hasOwnProperty('getElementById'))
      {
        alert("property not defined at this level");
        return;
      }
      // Overright the property:
      Document.prototype.getElementById = function(x) { return "test"; };
      // Ensure the override was successful:
      if (document.getElementById('foo') != "test")
      {
        alert("override failed");
        return;
      }
      // 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
           alert("delete failed to remove the built-in method");
      }
      else
        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.

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.

-----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
Received on Wednesday, 13 August 2008 18:13:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT