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