- From: David Bruant <david.bruant@labri.fr>
- Date: Sat, 24 Sep 2011 00:53:30 +0200
- To: Brendan Eich <brendan@mozilla.org>
- CC: public-script-coord@w3.org
Le 23/09/2011 21:37, Brendan Eich a écrit : > On Sep 23, 2011, at 12:31 PM, David Bruant wrote: > >> Hi, >> >> In the current form of WebIDL, if i run the following code (in a >> WebIDL-compliant environment): >> ----- >> var o = Event.prototype; >> delete o.currentTarget; // works with any other attributes >> ----- >> Then, all events afterward will not have a currentTarget property (since >> it's gone from the interface). >> In the DOM event spec, "currentTarget" is defined as an attribute on the >> Event.prototype object. This property must be a configurable (since not >> [[Unforgeable]]). Consequently, any script can remove it and events will >> no longer have a currentTarget property which is not what anyone want. >> >> Consequently, I would suggest to consider all attributes to be >> non-configurable regardless of [[Unforgeab(le)]]-ility. > Why is this a good idea? There are many ways to modify standard constructors and their prototypes, some destructive. Is it really important to forbid such freedom, just because one can make a mess? Currently, on Chrome and Opera (12), event attributes are configurable own properties (data in the former, accessor in the latter). Consequently, the freedom to prevent all events to have a "type" or "target" attribute doesn't exist by design. Do anyone miss that freedom? In other words, are there use cases of wanting this freedom at all or is it just a side-effect of putting properties on the prototype and defaulting to configurable=true because a choice has to be made? David
Received on Friday, 23 September 2011 22:54:08 UTC