Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
On Thu, Aug 14, 2008 at 4:59 PM, Cameron McCormack [EMAIL PROTECTED] wrote:
Hi Garrett.
I missed a couple of points in my last mail.
Travis Leithead:
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.
Garrett Smith:
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.
Web IDL wouldn't specifically say delete works on
Document.prototype.getElementById, but I think it should say how these
kinds of objects (Document, Document's [[Prototype]]) behave, e.g.
a property on an interface prototype object that corresponds to an IDL
operation has attributes { DontEnum }.
Document's [[Prototype]] would usually be Function or Object,
depending on the browser. Either way, it wouldn't really matter. If
you think it does matter, please explain how. Are you confusing
Document's [[Prototype]] with the Document.prototype property, BTW?
Regardless, it shouldn't matter to anyone.
JS libraries do exploit the
prototype chain to add methods etc.,
Are you talking about Prototype? They're somewhat inclined towards
changing that. There have been a lot of problems with that.
so it would be good if they could
do this with the blessing of a spec, rather than de factor behaviour.
Standardizing this behavior would only encourage them. It is a
horrible way to design an API. The fact that it doesn't work doesn't
mean it needs standardizing. The approach itself is inherently bad.
Given MS's interest in following Web IDL,
Why would Microsoft be concerned with that?
There are thousands of bugs in IE that are important and critical. I
see MS priorities are: Disabled OPTION - closed by design.
Implement DontEnum - WONTFIX. And WebIDL - worth following.
WebIDL is extends the boundaries of defining interface to address
browser incompatibility issues that do not help solve real problems.
It tries to specify more detail than is necessary for Interface
Definition Language.
there's a chance we could get
all four browsers doing the same thing, too.
All four browsers. You must mean Netfront, Obigo, iCab, and Opera.
All four of these browsers doing the same thing might seem like a good
idea (in a fuzzy way), however doing what same thing are we talking
about? That would be the determining factor. If that thing were
beneficial or harmful.
Or we could stick with interface definitions.
Garrett
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
On Sat, Aug 16, 2008 at 1:07 AM, Garrett Smith [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 4:59 PM, Cameron McCormack [EMAIL PROTECTED] wrote: Hi Garrett. [snip] Travis Leithead: [snip] Garrett Smith: [snip] Document's [[Prototype]] would usually be Function or Object, Correction: would usually be Function.prototype or Object.prototype... [snip] Garrett -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
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:[EMAIL PROTECTED]
Sent: Tuesday, August 12, 2008 11:20 PM
To: Travis Leithead
Cc: Web Applications Working Group WG; [EMAIL PROTECTED]; 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
[EMAIL PROTECTED] 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
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
Hi Garrett.
Travis Leithead:
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.
Garrett Smith:
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.
Web IDL wouldn’t specifically say “delete works on
Document.prototype.getElementById”, but I think it should say how these
kinds of objects (Document, Document’s [[Prototype]]) behave, e.g.
“a property on an interface prototype object that corresponds to an IDL
operation has attributes { DontEnum }”. JS libraries do exploit the
prototype chain to add methods etc., so it would be good if they could
do this with the blessing of a spec, rather than de factor behaviour.
Given MS’s interest in following Web IDL, there’s a chance we could get
all four browsers doing the same thing, too.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
On Thu, Aug 14, 2008 at 6:39 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 14, 2008, at 6:10 PM, Garrett Smith wrote: Document interface is an interface. An interface does not have defined implementation; it is merely a contract. IDL is for Interface Definition. The fact that some browsers expose Document as a global property does not need standardization. It would not be bad to have DOM readonly properties implemented with [[DontDelete]], [[ReadOnly]]. That could be one line in WebIDL, e.g. DOM readonly properties have [[DontDelete]] and [[ReadOnly]]. But it seems fairly obvious that this would have to be so, so it wouldn't seem critical to include that. All of the top four browser vendors would like to have these kinds of details clearly specified and to converge on interoperable behavior. I am not aware of any vendor that specifically wishes to diverge from interoperable behavior. As such, I hope the editor politely declines your requests to leave such things unspecified. what 'such things'? In general, leaving things unspecified does not prevent Web content from relying on them, People will do all sorts of things won't they? Regards, Maciej
[WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
Cameron, I recently became aware of Microsoft's involvement in the ECMAScript 3.1 effort as of 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. 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. I wondered if WebIDL makes any mention of the behavior of ECMAScript operators on host objects and how they should behave? - Travis Leithead - OM Program Manager - Internet Explorer
