W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

RE: All ECMAScript attributes should be non-configurable

From: Travis Leithead <Travis.Leithead@microsoft.com>
Date: Sun, 25 Sep 2011 03:00:41 +0000
To: Brendan Eich <brendan@mozilla.org>, David Bruant <david.bruant@labri.fr>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3834CE45B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
+IE9 (another example using configurable properties--as accessor properties on the prototypes). We did work around the performance issue using caches, as most sites don't mess with the configurability of the properties.

We [Microsoft] are strong supporters of the "configurable" DOM type-system. While you can "destroy-the-world" you can also use that power for good (with great power comes great responsibility :). Thanks to configurable properties, we were able to build a very useful tool to help all web developers identify potential compatibility problems on their web sites.


The tool is simple and replaces built-in DOM APIs with an inspection layer before funneling the calls through to the actual APIs. If the various accessor properties weren't configurable this tool would not be possible.

>-----Original Message-----
>From: public-script-coord-request@w3.org [mailto:public-script-coord-
>request@w3.org] On Behalf Of Brendan Eich
>Sent: Friday, September 23, 2011 5:53 PM
>To: David Bruant
>Cc: public-script-coord@w3.org
>Subject: Re: All ECMAScript attributes should be non-configurable
>On Sep 23, 2011, at 3:53 PM, David Bruant wrote:
>> 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?
>The "own" vs. prototype design is intentional. The non-configurable is too.
>The combination does make a destroy-the-world button. But is it really a
>problem? Same thing can happen with Object.prototype.toString.
Received on Sunday, 25 September 2011 03:01:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC