W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

[WebIDL] ES5 alignment: IE9's readonly and WebIDL configurable attribute

From: Travis Leithead <travil@microsoft.com>
Date: Fri, 29 Oct 2010 19:30:12 +0000
To: Cameron McCormack <cam@mcc.id.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>
CC: Kris Krueger <krisk@microsoft.com>, Adrian Bateman <adrianba@microsoft.com>, Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>, Tony Ross <tross@microsoft.com>
Message-ID: <9768D477C67135458BF978A45BCF9B38214AF1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Hey Cameron,

I have two issues that I'd like to talk about that are places where the latest WebIDL WD varies from the IE9 ES5 language binding. The two issues are related because they have to do with harmonizing the ES5 binding in WebIDL with ES5 itself. The funny thing is that both issues fall on opposite sides of the "harmonizing" argument, and IE9 and WebIDL took opposite stances on these issues. I hope the outcome of this discussion will lead to both a spec change in WebIDL and an implementation change in IE9.

The issues are:
1. The interpretation of 'readonly' in WebIDL syntax 2. The configurability of global properties that reference interface objects

ISSUE 1: The interpretation of 'readonly' in WebIDL syntax Summary - I think you've got this right in WebIDL and IE9's binding is wrong

Historically, DOM APIs that are readonly throw exceptions-although this is not very consistent. Consider these examples across various browsers:

document.body.tagName = "foo";

IE8     IE9     FF3.6   Chrome  Opera10.6
throws  throws  throws  silent  throws

window.document = "foo";

IE8     IE9     FF3.6   Chrome  Opera10.6
throws  throws  silent  silent  silent

When designing the JavaScript binding for IE9, our initial desire was to uniformly handle the interpretation of readonly to always throw because (as observed in most other browsers) readonly DOM APIs tend to throw an exception on assignment. Personally, I think this behavior is preferable to web developers who would like to spot errors in their scripts easier. So, in IE9's JavaScript language binding, we create "generic" setter functions for readonly properties whose sole job is to throw an exception when they are invoked. With the roll-out of the IE9 beta and intervening site-compat bugs, we've had to make exceptions to this policy by opting certain properties out of this behavior (like Event.target).

WebIDL specs readonly properties as getters with no setters and says that the language semantics determine the effect that assignment to these readonly properties will have. A reading of ES5 will uncover the fact that getters with no setters will silently fail, unless ES5 strict mode is enabled. This is a clear case where WebIDL is closely aligned with the intent of behavior of ES5. This is also probably the right design given IE9's experience to the contrary with site-compat issues. Naturally, browsers that support ES5 strict mode allow web developers to opt-in to a more strict handling of readonly properties if they want to.

My only recommendation here is that the WebIDL spec clearly state somewhere that in the ECMAScript binding, readonly properties will not throw exceptions unless ES5 strict mode is enabled. This isn't really obvious at first reading and is a significant side-effect of the language binding that merits its own callout.

ISSUE 2: The configurability of global properties that reference interface objects Summary - I think that WebIDL needs to change here to harmonize with ES5

In WebIDL syntax, interfaces without the attribute [NoInterfaceObject] will be bound in an ECMAScript implementation by creating two objects: an interface object and an interface prototype object. The first object, the interface object, will be referenced by a property on global object (e.g., the window). That property has the name of the interface and the attributes:

{ [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false }
(http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces)

Note that the [[Configurable]] property is false. There are two drawbacks that I see to this. First, as it relates to harmonizing with ES5, and second regarding programming flexibility.

In IE9, the same properties for the are:
{ [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: **true** }

because other native objects (e.g., Object, Function, String, Math, etc.) have the same property attributes:
{ [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }

Not only does this align with ES5, but it also future-proofs an implementation. 

If the properties that reference interface objects are not configurable, then there is no way that JavaScript can modify this property, or delete it should a current standard become irrelevant (say by something like Web DOM Core). Having the ability to customize and tweak the language binding for the DOM is an important consideration for IE (and presumably other browsers) to support scenarios where fix-up is needed for websites which can be done via Javascript (either by the UA or a 3rd party script). In IE9, we were very selective about which properties required [[Configurable]]: false, due to the implications. 

My request is that the attributes of global and namespace scope properties be changed to harmonize with ES5's globals: { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }

--
The high-order bit here is that the primary guiding principle for the ES5 binding in WebIDL should be harmony with the language. Both examples cited above represent places where both IE9 and WebIDL are not well-aligned with ECMAScript 5, and both are potential sore-spots for web developers. I hope that you to consider this feedback and update the spec appropriately.

Thanks,

Travis
Received on Friday, 29 October 2010 19:30:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC