For IE9 Platform Preview 4, we significantly re-architected how the Chakra JavaScript engine integrates into IE. This re-architecture, described in Dean’s post, subtly changes the programming model of the DOM for IE9 standards mode, making it consistent with new ECMAScript 5 capabilities, more interoperable with other browsers and aligned with emerging standards (WebIDL).
In this post I want to dive into the details of some of these programming model changes. You can take advantage of these enhanced DOM capabilities in the latest platform preview build. To highlight these changes, I’ll reference the Enhanced DOM Capabilities demo page that we released with the fourth Platform Preview.
That demo tests 24 capabilities that span 4 general categories:
- DOM object inheritance from native JavaScript objects
- JavaScript functional harmony with DOM objects
- Interoperable programming features
- New ECMAScript 5 support applied to DOM objects
The first two are closely related, so I’ll discuss them together:
DOM object inheritance from native JavaScript objects and JavaScript functional harmony with DOM objects.
Prior to IE9, the JavaScript engine was connected to the DOM via classic COM bindings. These legacy bindings allowed for only primitive object and function representations of the DOM to the JavaScript engine. Consequently, many basic JavaScript features that developers expected to be available to all objects and functions (including DOM objects like Window, Document, NodeList, etc.) were only available to native JavaScript objects (Array, Number, etc.).
The ECMAScript standard specifies basic operations that should work uniformly on all JavaScript objects, but allows “host objects” to deviate from those standard specifications. IE’s old JavaScript engine treated DOM objects as “host objects” which meant that basic JavaScript operations such as property access could behave oddly. While allowed by ECMAScript, inconsistent behavior between DOM objects and JavaScript objects created differences web developers had to account for.
For example, one common puzzler for many web developers was why IE DOM functions were reported as “object” to the typeof JavaScript operator rather than “function” (this capability is specifically checked in the demo as piece #10).
In IE9’s Standards Mode, we build our DOM as native JavaScript objects and functions rather than as “host objects,” thus enabling the features that web developers expect from native objects.
Interoperable programming features
The third group of capabilities showcase unique IE programming model behaviors that web developers commonly stumbled over. Because these behaviors were unique to the IE programming model, web developers found that their code didn’t work the same across different browsers.
As part of our new integration architecture, we removed many of the inconsistencies that kept the same script from working the same way across browsers. The programming model changes may cause sites that have conditional code written for IE to behave differently in IE9 than it did before. Therefore, it is worthwhile describing these changes in more depth.
Functions now enumerated
In IE8 and before, enumerating a DOM object did not include any of that DOM object’s member functions. IE9 now enumerates any property on a DOM object that has its “enumerable” property descriptor value set to ‘true’. (In other words, enumeration can be programmatically altered.) Functions are now enumerated by default to be consistent with other browsers.
Removed implicit function invocation
DOM functions in previous versions of IE were quite special. Not only did they claim to be typeof “object”, but they also retained a static ‘this’ value which referred to the object to which they belonged. Consequently, it was possible to cache a reference to a DOM function, and invoke it without explicitly passing the ‘this’ value:
// Works in IE8 and earlier versions
// Doesn’t work in IE9 or other browsers
var cachedGetElementById = document.getElementById;
cachedGetElementById(‘value’);
In IE9, this now throws an exception, as it does in other browsers. Code that formerly depended on this IE behavior may use the “.call” workaround:
// Works in IE8/IE9 and other browsers
// Doesn’t work in IE7 and earlier versions;
var cachedGetElementById = document.getElementById;
cachedGetElementById.call(document, ‘value’);
ECMAScript 5 provides a “bind” method for functions which allows them to take on the programming characteristics formerly supported by IE:
// Works natively in IE9 because of ECMAScript 5’s ‘bind’ API
var cachedGetElementById = document.getElementById.bind(document);
cachedGetElementById(‘value’);
Support for DOM exceptions and ‘const’ properties
The IE9 enhanced DOM now includes W3C-specified DOM exception objects and standardized error codes that web developers can use to determine (generally) the nature of a DOM API failure. These codes are commonly compared against well-defined ‘const’ properties to aid in code readability:
…
catch(ex) {
if (ex.code == DOMException.INDEX_SIZE_ERR)
…
}
The enhanced DOM provides the pre-defined ‘const’ properties as well as the architecture to throw and catch DOM exceptions.
Consistent toString behavior
With Chakra and the DOM fully integrated, the DOM does not have its own implementation of toString (a function that converts any object into a string form). While the old DOM’s toString implementation was similar to the JavaScript built-in version, it was not the same and often returned inconsistent or puzzling results. IE9 DOM objects now inherit and use the JavaScript built-in toString for more uniform results.
Separation of property and attribute storage
In the previous architecture, DOM objects had their own property storage. This property storage was the same as the storage location for attributes (those found in the HTML markup). With IE9’s new architecture, an element’s attribute storage is now separate from the dynamic properties assigned to an element’s script object. To illustrate this separation, consider the following example markup:
<div id=”myId” class=”c” user-defined-attribute=”test”>
In the above example, “id”, “class”, and “user-defined-attribute” are attributes. The div element’s JavaScript object also exposes similar properties:
// Get the JavaScript object representing the body
var divOb = document.getElementById(‘myId’);
divOb.id; // “myId”
divOb.className; // “c”
These JavaScript properties retrieve the values stored in an element’s attribute list. For example, “id” retrieves the value of the “id” attribute. “className” retrieves the value of the “class” attribute.
In previous versions of IE, any dynamically-added properties would “magically” appear in the element’s attribute list and vice-versa due to the shared storage location. This could lead to unexpected results:
<div id=”myId” class=”c” user-defined-attribute=”test”>
…
var divOb = document.getElementById(“myId”);
// The next statement unexpectedly adds “userProperty” as
// an attribute to the element.
divOb.userProperty = “test”// How many attributes?
alert(“Total attributes = ” + divOb.attributes.length);
IE9 and other browsers alert three total attributes (“id”, “class”, and “user-defined-attribute”), whereas previous versions of IE alert 4, adding “userProperty” to the list. The reverse example is more common—code that expects user-defined attributes to appear as dynamic properties:
<div id=”myId” class=”c” user-defined-attribute=”test” userAttribute=”test”>
…
var divOb = document.getElementById(“myId”);
// Get the “userAttribute” and “user-defined-attribute” value
// (only worked in IE8 and previous versions)
var value1 = divOb.userAttribute;
var value2 = divOb[“user-defined-attribute”];
We’ve seen a lot of code that expects this legacy IE behavior. The interoperable way to retrieve unknown attributes is to use “getAttribute,”
var value1 = divOb.getAttribute(“userAttribute”);
var value2 = divOb.getAttribute(“user-defined-attribute”);
and dynamic properties should not be queried through the attributes collection.
New ECMAScript 5 capabilities
In the last group of capability tests, new functionality provided by Chakra’s implementation of ECMAScript 5 is applied to the DOM. One of the primary goals for the enhanced DOM in IE9 was to provide a representation of the DOM that made logical sense within the context of the ECMAScript 5 language semantics. This was made much easier because one of the primary goals of ECMAScript 5 is to better support the functionality needed by DOM objects! In our implementation, we represented the DOM using as many native ECMAScript 5 language features as possible, including extensive use of accessor (getter/setter) properties.
This native integration allows all of the new ECMAScript5 features to work equally well with native objects as with DOM objects.
The enhanced DOM capabilities demo shows only 24 samples of what is possible when the DOM is fully integrated with an ECMAScript 5-capable JavaScript engine like Chakra. We are very excited about this support in IE9 and want to help get better interoperability for ECMAScript language bindings across browsers. An important step is standardizing these binding within the W3C, and we’re happy to contribute to that effort.
W3C web standards have always supplied a language binding for ECMAScript implementations as a way to translate the standard IDL (Interface Definition Language) into JavaScript objects. However, these bindings lacked sufficient detail to create much more than a simple “host object” binding (a binding without consideration of the full spectrum of ECMAScript language features). While other browsers have a much more comprehensive language binding than simply “host objects,” integration inconsistencies remain. These inconsistencies can really frustrate JavaScript framework developers who wish to write abstraction layers and features on top of the basic language support. The need for consistency led to a proposed standard called WebIDL (Web Interface Definition Language). The WebIDL specification describes in much more precise detail, how to translate a given W3C spec written using WebIDL into JavaScript objects.
In a follow-up post, I will describe in more detail how we used WebIDL to inform and guide the development of the IE9 enhanced DOM.
Please testdrive the IE9 enhanced DOM. We look forward to your comments and feedback.
Travis Leithead
IE Program Manager