Understanding the advanced features of DOM IE9

For the fourth preliminary release of the IE9 platform, the way in which the Chakra JavaScript subsystem is integrated into IE has been significantly rebuilt. This redesign, described in the Dean publication , slightly changes the DOM programming model for the IE9 standards mode, ensuring its compatibility with new ECMAScript 5 features, a greater degree of interaction with other browsers, and compliance with new standards ( WebIDL ).

In this publication it is planned to examine in detail some of the changes in the programming model. The benefits of these advanced features of the DOM can be found in the latest preliminary release of the platform. To highlight these changes, I refer to the DOM advanced features demo page , which was created for the fourth preliminary release of the platform.


')
In this demonstration, 24 possibilities are tested, which are divided into 4 main categories:

• Inheriting a DOM object from its own JavaScript objects
• Functional consistency of JavaScript with DOM objects
• interoperable software components;
• support for new ECMAScript 5 applied to DOM objects.

The first two categories are closely related, so consider them together.

Inheritance of a DOM object from native JavaScript objects and functional consistency of JavaScript with DOM objects.

Prior to IE9, the JavaScript subsystem was associated with the DOM model through the classic COM model bindings mechanism. These outdated bindings are valid only for the primitive representation of DOM objects and functions in the JavaScript subsystem. Consequently, a lot of the basic JavaScript functionality, which, according to the expectations of the developers, should have been available for all objects and functions (including such DOM objects as Window, Document, NodeList, etc.) was actually available only to its own objects. Javascript (such as Array, Number, etc.).

The ECMAScript standard establishes basic operations that should work the same in all JavaScript objects, but allows “base objects” to deviate from these standard settings. The old JavaScript subsystem in IE perceived DOM objects as “base objects”, which means that basic JavaScript operations, such as accessing properties, could behave strangely. Being resolved by ECMAScript, the inconsistent behavior of DOM objects and JavaScript objects created difficulties for the web developers responsible for them.

For example, one of the most common questions for many web developers was why IE DOM functions returned to the typeof JavaScript operator as an “object” rather than as a “function” (this feature was specifically tested in part # 10 of the demo version).

In standard mode, IE, the DOM model is built as native JavaScript objects and functions, rather than as “base objects”, which ensures the availability of the functionality that web developers expect from their own objects.

Interoperable software components

The third group of opportunities demonstrates the unique behavior of the IE programming model, which usually causes difficulties for web developers. Since this behavior existed only in the IE programming model, web developers found that their code did not work equally in different browsers.

As part of the new integration architecture, many inconsistencies have been removed that prevent the same script from working in the same way in different browsers. This programming model may lead to the fact that sites with a special code created for IE in IE9 will behave differently than before. Therefore, it makes sense to describe these changes in more depth.

Functions are now enumerable.

In IE8 and earlier versions, the enumeration of a DOM object was not related to any member functions of the DOM object. IE9 now lists all the properties of a DOM object, whose "enumerable" descriptor is set to true. (In other words, the enumeration can be changed programmatically.) Functions are now enumerated by default for compatibility with other browsers.

Removed implicit function call

DOM features in previous versions of IE were rather non-standard. They not only looked like a typeof object, but also saved the static value “this”, referring to the object to which these functions belong. Therefore, it was possible to cache the reference to a DOM function and call it without explicitly passing the value of “this”:

// Works in IE8 and previous versions

// Doesn't work in IE9 and other browsers

var cachedGetElementById = document.getElementById;


cachedGetElementById ('value');

In IE9, this will now raise an exception, as happens in other browsers. In code that previously depended on this IE behavior, you can use the .call workaround:

// Works in IE8 / IE9 and other browsers

// Does not work in IE7 and in previous versions
var cachedGetElementById = document.getElementById;


cachedGetElementById.call (document, 'value');

In ECMAScript 5 for functions, there is a “bind” method, which allows them not to reject programming features previously supported by IE:

// Initially, it works in IE9 due to the ECMAScript 5 “tied” API

var cachedGetElementById = document.getElementById.bind (document);


cachedGetElementById ('value');

Support for exceptions and "constant" properties of the DOM model

In the enhanced DOM IE9, there are now W3C conditioned objects and standardized DOM exception error codes that web developers can use to determine (in general) the nature of the DOM API failure. These codes are usually compared with well-defined "constant" properties to improve the readability of the code:

...

catch (ex) {


if (ex.code == DOMException.INDEX_SIZE_ERR)


...


}

The enhanced DOM provides predefined “constant” properties, as well as an architecture for invoking and catching DOM exceptions.

Holistic toString behavior

With the full integration of Chakra and the DOM model, the latter has no own implementation of toString (a function that converts any object into a string). Although the old model DOM implementation toString was similar to the built-in version of JavaScript, it was not exactly the same and often led to inconsistent or confusing results. Objects of the DOM in IE9 now inherit and use the built-in JavaScript function toString to get the standard result.

Separation of property and attribute storage

In the previous architecture, DOM objects had their own property store. This property repository matches the repository location for the attributes (which can be found in the HTML markup). In the new IE9 architecture, the element attribute store is separated from the dynamic properties assigned to the element's script object. To illustrate this separation, consider the following markup example:

<div id = "myId" class = "c" user-defined-attribute = "test">

In this example, the attributes are “id”, “class” and “user-defined-attribute”. The JavaScript object of the div element also provides 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 the attribute list of an element. For example, “id” retrieves the value of the attribute “id”, and “className” retrieves the value of the attribute “class”.

In previous versions of IE, any dynamically added properties could “magically” appear in the element attribute list and, conversely, disappear due to the general location of the repository. This could lead to unpredictable results:

<div id = "myId" class = "c" user-defined-attribute = "test">


...


var divOb = document.getElementById ("myId");


// The following statement unexpectedly adds "userProperty" as

// attribute to element.

divOb.userProperty = "test"



// How many attributes?


alert ("Total attributes =" + divOb.attributes.length);

IE9 and other browsers signal three common attributes (“id”, “class” and “user-defined-attribute”), while previous versions of IE signal four attributes by adding “userProperty” to the list. The reverse example is more common - code that expects the appearance of custom attributes as dynamic properties:

<div id = "myId" class = "c" user-defined-attribute = "test" userAttribute = "test">


...


var divOb = document.getElementById ("myId");

// Get the value of "userAttribute" and "user-defined-attribute"


// (works only in IE8 and in previous versions)


var value1 = divOb.userAttribute;


var value2 = divOb ["user-defined-attribute"];

We have seen a piece of code in which this outdated IE behavior is assumed. The interoperable way to get unknown attributes is to use getAttribute.

var value1 = divOb.getAttribute ("userAttribute");

var value2 = divOb.getAttribute ("user-defined-attribute");

In this case, you should not query for dynamic properties using the attribute collection.

New ECMAScript 5 Features

In the last group of capabilities tests, the new functionality provided by the ECMAScript 5 implementation in Chakra was applied to the DOM. One of the main goals of improving the DOM model in IE9 was to provide a representation of the DOM model, which made logical sense in the context of the semantics of ECMAScript 5. This was made much easier because one of the main goals of ECMAScript 5 is to improve the support for the functionality required by DOM objects ! In our implementation, we imagined that the DOM model uses as many ECMAScript 5 own capabilities as possible, including extensive use of the properties of the access method (getter / setter).

Thanks to this integration of platform functionality, all new ECMAScript5 functionality works equally well with both native objects and DOM objects.

In the demonstration of the advanced features of the DOM, only 24 examples of what is possible with the full integration of the DOM and the JavaScript subsystem with ECMAScript 5 support, such as Chakra, are shown. We are very interested in this support in IE9 and plan to help achieve better interaction for ECMAScript language bindings in different browsers. An important step is the standardization of these bindings in the W3C consortium, and we will be happy to contribute to this work.

The W3C web standards already have a proposal for language binding implementations for ECMAScript as a way to translate standard IDL (interface definition language) into JavaScript objects. However, these bindings lacked some details to create something more than a simple “base object” binding (that is, a binding without taking into account the full range of ECMAScript language functionality). Since other browsers had much more complete language bindings than just the “base objects”, integration inconsistencies persisted. These inconsistencies can actually upset developers on a JavaScript platform who want to write abstract layers and functions at the top level of basic language support. This need for compliance led to a proposed standard called WebIDL (Web Interface Definition Language). The WebIDL specification describes with much greater accuracy the translation of the existing W3C specification created using WebIDL into JavaScript objects.

The next post will give a more detailed description of how we used WebIDL to inform and guide the development of the advanced DOM in IE9.

Please test the extended DOM IE9 model. We are looking forward to your comments and feedback.