With Internet Explorer 8 we introduced several new JScript language features including native JSON support and accessor methods for Mutable DOM prototypes. Of course, any new language feature introduces compatibility risk and one of the main pieces of feedback we received was that we needed to provide a smart way for developers to opt in or out of these new language features.

 

So in the JScript engine shipped as a part of Internet Explorer 8, we introduced a versioning switch which enables developers to choose the JScript language set they want to support. Web developers can opt-in/opt-out of select JScript language features by using IE8’s Document Compatibility, which depends upon the layout (or document) mode in which web content is loaded.

 

Potential Issue: Example

As an example, let’s look at IE8’s native JSON support. We added this support to the engine by adding a global JSON object with built-in parse() and stringify() methods, as per the draft ES3.1 specification, now called the ECMAScript Fifth Edition. Now, for the sake of example, let us pretend that the JScript engine did not allow language versioning and a site implemented a JSON call like this:

 

   1: if(!this.JSON) // check for non-existence of JSON object/functions

   2: {

   3:     //<define a JSON object>

   4:     //<define a non-standard compliant encoder function – JSON.encode>

   5:     //<define a non-standard compliant parser function – JSON.parse>

   6: }

   7: 

   8: //somewhere in the code

   9: JSON.encode(myObj);                         

 

For IE7, since no JSON object existed by default, the if check would evaluate to true and the user defined JSON object and encoder/decoder methods would be defined. The call to JSON.encode() would work as wanted.

 

However, for IE8, the existence of the native JSON object would cause the if check to evaluate to false and no user defined method would be available. The call to JSON.encode() would now fail, which would produce unexpected application behavior, since no such method was defined.

 

JScript Versioning in Internet Explorer 8 (for Web Developers)

Web developers can now avoid such issues by choosing an appropriate layout (or document) mode for their content. Choosing the layout mode as “Internet Explorer 8 Standards Mode” opts in to the JScript language features supported by version 5.8 JScript engine. Choosing the layout mode to be any mode other than the “Internet Explorer 8 Standards” mode, would imply an opt-in to support JScript language feature set equivalent to the one shipped in version 5.7 of the JScript engine (equivalent to the one shipped in IE7). Going back to the example above, the site owner can either update the code to start taking advantage of native JSON support and use the “Internet Explorer 8 Standards” mode, or can choose any other layout mode to use the existing code as is, thus maintaining  compatibility with IE7.

 

While a dependency on the document mode implies that developers will need to make a switch to both IE and JScript level features and can’t single out/opt-in only to the JScript changes, we did not want to introduce a new version vector specifically for the JScript engine. We wanted to support the same system used by IE8 overall for standards support.

 

You could read more about IE8’s Compatibility View feature in Scott Dicken’s blog Just The Facts: Recap of Compatibility View and the MSDN documentation for Defining Document Compatibility.

 

JScript Versioning in other JScript Hosts (for JScript Host Developers)

Apart from Internet Explorer, there are various other hosts such as Windows Script Host, CScript etc. which host the JScript engine, To avoid similar compatibility issues and enable hosts to choose a particular JScript language feature set, the JScript engine now exposes an IActiveScriptProperty::SCRIPTPROP_INVOKEVERSIONING property.

 

To opt in to a set of language features that should be supported by the JScript script engine, the host needs to invoke the IActiveScriptProperty::SetProperty and set SCRIPTPROP_INVOKEVERSIONING to one of the values below during the engine initialization:

  • 1 (or SCRIPTLANGUAGEVERSION_5_7):  To use the language features equivalent to those shipped in Version 5.7 (or IE7) of the JScript engine
  • 2 (or SCRIPTLANGUAGEVERSION_5_8):  To use the language features available in Version 5.8 (or IE8) of the JScript script engine. This includes features available in version 5.7 and the language changes introduced in version 5.8.

 

By default, the set of language features supported by the JScript script engine is set to 0 (or SCRIPTLANGUAGEVERSION_DEFAULT), equivalent to the language feature set shipped in version 5.7 of the JScript engine, unless the host chooses to support a different default behavior.                                                                                                                                                  

 

List of features versioned

Right now, only nine JScript features are versioned like this:

  • Native JSON support – This would introduce a new built-in JSON object, and the following built-in methods – JSON.parse(), JSON.stringify(), Date.toJSON(), Number.toJSON(), Boolean.toJSON() and String.toJSON()
  • Support for accessor methods for enabling Document Object Model prototypes
  • Default the separator to “,” if the separator value is ‘undefined’ in Array.prototype.join
  • Return the length of the resultant array instead of ‘undefined’ for Array.prototype.unshift
  • Call toString() if precision is ‘undefined’ instead of throwing a “RangeError” for Number.prototype.toPrecision
  • Support for array subclassing
  • Support for trailing commas in object literals
  • Implemented Error.prototype.toString to provide better error messages
  • Support for index operator [] on string values

 

I hope JScript versioning will help ensure that the IE8 end user experience is compatible with IE7 and will give developers some time to update their code to take advantage of these new language enhancements.

 

Gaurav Seth

Program Manager, JScript