JavaScript: Same Code, and a Standardized Test Suite

Being all in with HTML5 means being committed to enabling developers to use the Same Markup on the Web, and that includes the same JavaScript code.

The Chakra JavaScript engine in the latest Platform Preview release of Internet Explorer 9 includes significantly improved support for the ECMAScript (ECMA-262) standard, including features new to the recently finalized ECMAScript Fifth Edition (often called ES5 for short). This also includes complete support for JavaScript tests in Bucket 6 of the Acid3 test suite. Microsoft has been a key contributor to the ES5 effort. During the drafting of ES5, Microsoft was the first to provide a private reference implementation of the specification along with conformance tests to the ECMA Technical Committee 39 (TC-39).

Having the same markup work correctly across the web requires comprehensive tests that all browsers can rely on to deliver interoperable implementations. Microsoft has worked with the W3C to provide definitive test suite specifications for HTML, CSS, SVG, and other web standards. In recent months, we’ve contributed nearly 200 new tests to the W3C for these standards.

Unlike specifications governed by W3C, JavaScript does not have a definitive test suite owned and sponsored by ECMA. In the absence of such a suite, browser vendors and others have tried to fill the gap. We have published a suite of tests for new features in ECMAScript 5 through Codeplex, and will soon publish them on the Internet Explorer Testing Center. Other browser vendors have their own test suites. While all these tests are useful, they also have inconsistencies: different coverage of standards, different test harnesses, and implementation issues. Many in the industry have questioned whether we should have a more consistent way to test ECMAScript by working together.

That’s why Microsoft is now working with other browser vendors and other members of TC-39 to create an official test suite for ECMAScript sponsored by ECMA. We plan to help build this test suite, and contribute tests to it. We also welcome other browser vendors’ contributions to this effort.

Ensuring the same script works everywhere is vital to web developers. We look forward to hearing your feedback as we can continue to work on making this a reality.

Unlike other browsers, I know some versions of IE won't accept trailing commas in array and object literals (and maybe other contexts; I'm thinking of {a: 1,} or [0,]). Other browsers also allow keywords to be used in object literals (like {default: 3}). Will IE 9 allow any of those those bits of syntax? Or is there some indication other browsers will reject the syntax as IE does in the future?

(I don't think I can test for myself with the Platform Preview because I don't have a Vista or better machine or VM.)

Does Microsoft have anything to say about Google's Sputnik tests? (Like, "the more test suites the merrier" or "some of those tests look for the wrong behavior"?)

Well, I have a question about your ES5 proposal. When calling Object.defineProperty(obj, "prop", {get: function() { return 'value'; }}) and then obj.prop="set?", we face no error. it seems that everything goes as if we add an empty set defined for the property (which seems to be the case, see getOwnPropertyDescriptor (the empty function seems to be native))

Now, the spec. It says if no "set" has been defined, "UA should use the default value". The problem is that I found no place in the spec that say what's the default value. For me, it should be null, or a function that throw a "Property was readonly error". So, my question is what exactly requires the spec ? why did you implement it that way (no error throw) ?

It looks like you are running the ES5Conform suite probably from you local machine and the tests are running in a compatibility mode (the intranet zone defaults to compat mode). You need to explicitly set the mode to IE9 Document Mode and rerun the tests if you want to exercise the ES5 support.

Sweet! I'm really happy that you guys finally got importNode covered…and the fact that you're trying to cover as much of the standards as possible is great! Also it's nice to see a more objective browser comparison.

You guys have the resources to make IE totally awesome and the only thing missing is full codec support. When looking at the Wikipedia pages for audio and video element codec support IE only supports proprietary codecs. If you guys really want to truly make us happy let's see that solid green across all those codecs instead of more politics otherwise we'll all be using Flash and/or other plugins well in to the 2020's for media. Okay, cue the Hollywood hack who will criticize my post while he's on lunch break between suing grandmothers because all they care about is milking people for money!

Lastly if Microsoft wants to truly make amends with the designers IE9 should be released for XP. Of course I doubt that will happen with the whole buy a 7 license. It's politics like these examples that severely limit my enthusiasm for the work being done and should have been done say five years ago. One can't argue against 60%+ market share and a GUI that doesn't work against productivity like Vista and even worse 7.

As much as I appreciate the hard work being put in to IE9 Microsoft is still ultimately holding the web back and it's ultimately purely for political reasons.

What makes you think that people using XP/IE6 will suddenly upgrade to IE9? Clearly these people are not interested in cutting edge technology, and will only do so if there are *very* good reasons for it. (i.e.: the sites they visit start breaking – really badly.) Commercial sites won't do this – it has to start with freebie, or amateur sites.

In this case, XP users can upgrade to Safari, Opera, Chrome or Firefox; Vista/Win7 users can also opt for IE9.

There is no real need for IE9 on XP, there are alternatives. (Ironic, isn't it? Your biggest competitors bailing you out <grin>)

Moving the web forward is about content, not the technology how to access that content.

If people can't access (some of) the content they want they'll switch, otherwise…

@Allen W-B: Wow, thanks for digging into that! I'm sorry I couldn't report it properly at first since I can't run the IE9 PP. I put this into Connect (with a reference to your comment), although I recognize that's probably redundant and it may just be closed as such.

Glad it turns out ES5 allows the trailing commas; accidental trailing commas (e.g., when hastily editing an object literal in a script and not testing cross-browser) have caused some embarrassing problems for apps I worked on.