Chakra: Interoperability Means More Than Just Standards


How do we decide whether to implement a feature that isn’t included in a standards specification? Like all browser providers, we often have to make this decision. In this post, I’ll use some real-world JavaScript examples to illustrate some of the principles we use to deliver an interoperable browser when the standards specification isn’t enough.

In an ideal world, a standards specification is the complete story. A JavaScript implementation would just include everything in the ECMAScript specification and nothing more. We believe that specifications published by standards organizations such as Ecma International or the W3C are essential for interoperability among web browsers. Ideally, such specifications tell the browser implementers what features they need to provide and tell web developers what features they should be able to use.

In the real world of the web, things are not so clear-cut. Specifications are seldom perfect and sometimes they are intentionally incomplete or ambiguous. Having served as editor for the ES5 specification, I know that there are always issues that don’t get fully resolved. The result is that there are widely implemented and used features that are not defined by any standard specification. If you are trying to build a browser that runs the existing web you have to implement many features that are not defined by a standards specification.

What’s the Real Regular Expression Grammar?

We built Chakra by carefully following the ECMAScript 5 (ES5) specification including the grammar for regular expressions. But when we started testing on actual web sites we started seeing pages not work because of syntax errors on some regular expression literals. For example, we failed on regular expressions containing a right square bracket such as:

next = /]/.exec(buffer);

The reason was that the grammar for regular expressions in the ECMAScript standard includes ] in a list of characters that you cannot directly use as a match character. The specification says that /]/ is illegal and instead you need to say /\]/. It turns out that it is important that [ is restricted in this manner because otherwise it wouldn’t be possible to parse literals like /axyz[a-d]qwer/. However a lone ] that isn’t preceded by a [ really doesn’t present a parsing problem. But the standard still says that it is illegal.

In practice, all browsers accept regular expressions such as /]/ and web developers write them.

Consensus feature is a term we use to describe such features that are not part of any standard but which are universally implemented in an interoperable manner. In general, IE9 and any other new JavaScript implementation need to implement such consensus features in order to work with actual web content. The real challenge is identifying them, as they are not included in the standards specifications.

We recognize that we have to support these sorts of consensus features and we will also be working to make sure that they get included in future editions of the appropriate web standards. However, not all JavaScript extensions are universally or uniformly implemented.

Why Doesn’t IE9 have those _ _ methods?

ES5 includes support for getter/setter methods. Similar features have been available in some web browsers for many years. Over that period, browser developers experimented with various syntaxes and APIs for defining such methods. Prior to ES5, the most widely implemented API for defining getter/setter methods used two methods named __defineGetter__ and __defineSetter__. Surrounding method names with two underscore characters is a convention that some browser developers use to identify methods that are either experimental features or which access unique low level capabilities of a specific JavaScript implementation.

ECMA TC39 members agreed that getter/setter methods should be included in the ES5 specification because their value had been clearly demonstrated. However, TC39 also chose to design a new API for defining them and to not standardize the __defineXXX__ APIs.

Why did TC39 do this? Because of significant differences in the behaviors of the browsers that had provided that API. Standardizing on a common semantics for these methods would mean that some or perhaps all existing browser implementations would have to change to conform to the new semantics. That would probably break some applications that were written to work with those specific browsers.

Another reason was to maintain consistent naming conventions. No other built-in names in ECMAScript begin or end with underscore characters. The association of such names with experimental or an implementation specific feature is widely known and using that convention for a standardized feature would be both misleading and would dilute the utility of the convention for future experiments.

TC39 developed a new API based upon the Object.defineProperty method. This API not only supports defining getter/setter properties but also support other new capabilities of ES5. The __defineXXX__ methods were left out of the ES5 specification.

Browsers that already provide the __defineXXX__ API are free to continue to supporting them unchanged for compatibility reasons. However, new code that is written to be interoperable among browsers supporting the ES5 standard should use Object.defineProperty to define getter/setter properties.

We still get requests that we add the __defineXXX__ APIs to IE9. We understand why. Some developers already have code that uses those APIs and they would like that code run on IE9. However, we believe that supporting these APIs would not be in the best interests of the interoperable web. TC39 has already considered this API and concluded that it should not be standardized. If IE9 added support for the __defineXXX__ APIs, that action would move that API closer to being a permanent consensus feature of the web and would be essentially overriding the decision of TC39.

Unfortunately, in the short term this creates a small amount of additional work for developers currently using the legacy API. However, it is trivial to create a simple compatibility library for your code that implements the __defineXXX__ APIs in terms of Object.defineProperty.

A Malfunctioning Consensus Feature

Within JavaScript code, a function can be referenced and called in code that precedes the actual function declaration. This is possible because JavaScript logically “hoists” all function declarations to the top of the containing code body. JavaScript also allows more than one function declaration to exist for the same function name. Consider a simple test function:

function testFuncDeclarationOrder () {
   f1();
   function f1() {alert("first f1")}
   f1();
   function f1() {alert("second f1")}
   f1();
}

When called, this function produced the alert sequence: “second f1”, “second f1”,”second f1”. The reason is that JavaScript actually processes the function as if it had been written as:

function testFuncDeclarationOrder () {
   function f1() {alert("first f1")}
   function f1() {alert("second f1")}
   f1();
   f1();
   f1();
}

The ECMAScript specification has historically placed only one restriction upon the placement of function declaration. The ECMAScript standard does not include the ability to place a function declaration inside the body of a control structure statement. For example:

if (someCondition) {
   function f1() {alert("f1")}
}

The above code would produce a syntax error if parsed in according to the ECMAScript specification. However, if you try this in any browser, you will find that you do not get an error. Supporting function declarations anywhere a statement is permitted is a consensus feature of the web. If so, why wasn’t it included in ES5? Section 12 of the ES5 specification actually says something about this:

NOTE Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations. Because of these irreconcilable difference, the use of a FunctionDeclaration as a Statement results in code that is not reliably portable among implementations. It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. Future editions of ECMAScript may define alternative portable means for declaring functions in a Statement context.

What does this dense statement mean? Simply stated, the behavior across different browsers varied so widely that reconciling them was impractical.

So what does IE9 do? Does it disallow such statement level function declarations as recommended by ES5? No, it treats such declarations exactly like previous versions of IE.

Why did we make that decision? Because previous experiments by browser implementers found that rejecting such declarations broke many existing web pages.

This may seem surprising. How can a web page rely on features that behave different across browsers and still be interoperable among browsers? One possibility is that the code isn’t actually used. It may be in a function that is never called or whose result is not essential to the operation of the page. However, if the JavaScript implementation treated these functions as syntax errors the entire script would be rejected even though the code is never called.

We don’t like having to implement a feature that is such a hazard for developers. But its existence is enshrined in the web so we really had no choice.

So What About const?

We are sometimes asked whether we will support the const declaration in IE9. const is a non-standard JavaScript extension that provides a way to declare “named constant” values. A typical usage might be something like:

const pi=3.14159;

Several browsers support this feature but there are significant differences in their handling of unusual situations and in what they define to be errors. Here is an example that shows some of the differing behavior among the browsers that “support” const:

// a function with multiple const declaration for the same name
function f() {
   alert('executing within f');
   const x=1;  //declare constant x as 1
   alert(x);
   const x=2;  //redeclare constant x as 2
   alert(x);
   x=3;        //try to assign 3 to x
   alert(x);
}
alert('about to call f'); f();

Depending upon the browser, running this code it might:

  • Issue a syntax error and not load the page.
  • Throw an exception when f is called.
  • Alert: ‘1’, ‘2’, ‘2’. This means conflicting const declarations are allowed but the assignment was ignored.
  • Alert ‘1’, ‘2’, ‘3’. This means that const was treated just like var.

Basically, only very simple uses of the const declaration are interoperable among browsers that support the declaration. Many more elaborate uses, or scenarios that might trigger some error condition, are not interoperable among those browsers.

An actual JavaScript implementation can’t only support the trivial common use cases. A real implementation also has to do something for all the odd edge cases and error scenarios that exist on real web pages. Arguably, it’s mostly for situations like this that we have standardized specifications. It’s generally pretty obvious what should be done for the simple common use cases. It’s the edge cases that require a standards specification in order to have interoperable implementations.

TC39 seriously considered including const in ES5 and it was in early ES5 drafts. However, there were many issues about how it should be defined and how it interacts with other declarations. Ultimately, there was agreement within TC39 that standardization of const should wait for the “next” edition of the specification where perhaps some of these other problems could also be addressed. Basically, TC39 decided it did not want to standardize on a flawed feature. Instead, it chose to defer any standardization of const for a future where a single improved design could be incorporated into all browsers.

So, what is IE9 doing with const? So far, our decision has been to not support it. It isn’t yet a consensus feature as it has never been available on all browsers. There is no standard specification and there are significant semantic differences among all the existing browser implementation. In addition, we know that TC39 decided not to standardize any of the existing alternatives and wants to reconsider it in the next ECMAScript revisions.

We understand the desire of many web developers to have such a declaration. But we also don’t want to create another situation like conditional function declarations where the feature has to exist but web developers better not use it if they care about browser interoperability. In the end, it seems like the best long term solution for the web is to leave it out and to wait for standardization processes to run their course.

Principled Decision Making

These are just four JavaScript specific examples illustrating the sort of decisions we have to make in creating IE9. Many similar issues come up with regard to other web standards and consensus features. For each we perform a similar analysis. What does the standard say? How many websites actually require it? Is it a consensus feature with a common semantics? Are there multiple, incompatible variants of the feature? Is a standards committee working on it? Do any test suites exist? Would our adoption help or hinder the standards processes? In the end it is a judgment call, and we try hard to make principled consistent decisions.

Allen Wirfs-Brock
Microsoft JavaScript Language Architect

Comments (48)

  1. blah says:

    I guess to Microsoft, interOperaBility means shamelessly stealing Opera's JS engine name.

  2. Sylvain Galineau [MSFT] says:

    Opera's engine is called Carakan.

  3. Raffi says:

    @blah

    Uhh, Opera's is called Carakan, and who even cares anyway?

  4. jabcreations says:

    Opera's back-trace isn't hidden and tells you what function made the call to the function that failed.

    IE and Opera will capture some errors that Firefox won't.

    Firefox will capture some other errors and warnings.

    Safari will make you aware of invalid mime types.

    If you code JavaScript and don't use all four rendering engines and their respective scripting engines then you're only shooting yourself in the foot.

    Older versions of IE would not even declare there was an error when one was encountered and simply would quietly stop executing scripting.

    Error messages that point out exactly what happened and provide a method to back-trace what function called the failing function in example help quicken the pace of development.

  5. Max says:

    Thanks for the insights.  In the past, if a particular feature didn't make it into a browser, I would assume it was simply because there wasn't time.  But this sort of post reveals that it's probably much more deliberate than that, which things get implemented and how.  It would be cool if an IE8 addon was released (or a standalone site, like the W3C Validator website) that helped web devs determine if their site was IE9-ready.

    Also, the Chakra name is cool, but it would be if a subject a little less, uh, holy, was chosen.

  6. William J. Edney says:

    Allen –

    Thanks for the great article.

    Can you or other Microsoft personnel here answer the question as to whether Chakra will be supporting the Web Workers part of the HTML5 spec in IE9?

    Thanks!

    Cheers,

    – Bill

  7. Prior Semblance says:

    It's good to see that features are being added because it makes sense and not because random people want them added.

  8. thenonhacker says:

    Most people are speechless now that Microsoft is getting very serious on Web Standards and Interoperability.

    There are childish comments like "Microsoft shamelessly stealing Opera's JS engine name" and all that sh*t, but as a Firefox user, I should say: Shut up Opera Kiddies.

  9. Lorenzo says:

    I must say well done then! But i preferred the python-like syntax

  10. @davetayls says:

    im agreement with thenonhacker, at the end of the day it will allow web developers to spend more time playing …ah i mean…innovating

  11. Harry Richter says:

    @ all

    Good news: http://www.businesswire.com/…/en

    "MPEG LA’s AVC License Will Not Charge Royalties for Internet Video That Is Free to End Users Through Life of License"

    Harry

  12. Olivier says:

    "Specifications are seldom perfect and sometimes they are intentionally incomplete or ambiguous." : take that "Hixie"!

    I agree that browsers shouldn't break existing websites, but I'm not sure it's a good idea to accept stuff like the regex "/]/". The developers made a mistake, but if they had tested their code in a browser not accepting this syntax, they would have found the error and they would have corrected it. Regexes should be standards (and strict) between every languages.

  13. Frank says:

    Looks like IE9 still fails horribly on CSS3 flexbox stuff.

    See the Fail Whale here: img826.imageshack.us/…/ie9flexfail.png

    Here's what is should look like (use a real browser like: Firefox, Safari, Chrome) http://www.gwilym.com/…/example-1.html

  14. David Bruant says:

    About const : "An actual JavaScript implementation can’t only support the trivial common use cases.". I agree.

    However the example you provide doesn't prove your point in my opinion. To write the following code, you have to be really tired :

    function f() {

      const x=1;  //declare constant x as 1

      const x=2;  //redeclare constant x as 2

      x=3;        //try to assign 3 to x

    }

    Why would anyone write twice "const x" and moreover change the value ? These are the cases where a decent spec would say that a error should be thrown. A less decent spec would say "The behavior is undefined. Do it at your own risk".

    I think that the correct behavior is to throw an error since an interpreter should help detecting obvious semantic errors and this is clearly one.

  15. ItsAnExample says:

    David– obviously, they simplified what a real example would look like, in which there would be dozens, hundreds, or thousands of intervening statements between the constants. And while you may think you know what the correct behavior is (and I tend to agree) that begs the question of why other browsers haven't developed a consensus behavior here.

    The right thing to do is for the spec to specify it and the browsers to implement it.

  16. Duh says:

    Frank: They don't "fail"– they didn't try. "Flexbox" is defined by http://www.w3.org/…/css3-flexbox, which is only in its first public working draft. It's not a candidate recommendation or at last call, or at any other similar state of completion. IE9 does not attempt to support a spec which will almost certainly change before completion, making all of those "real" browsers "break the web" with incompatible behavior.

  17. Meni says:

    Harry Richter, if confirmed (didn't see this yet on any other site other then BW, you are quick), this IS great news! I just wish they didn't wait this long, and hadn't let google spend $ and time on WebM. It's the same grievance i have with Microsoft with SVG :-), and it's the same against Sun with open-sourcing Java

  18. mitch074 says:

    @David Bruant: they gave an example that covered the three main cases of 'const'( mis)use:

    – using a constant as a value that must NOT be changed after initializing (error if trying to redefine it)

    – using a constant as a value that can't be changed without specific operation (you need 'const' declared before the new affectation)

    – using a constant as a variable.

    Now, this usually occurs over LONG pieces of code, and not as fast as the given example; and, as said, it is dealt with differently across browsers:

    – those that implement 'const' the way it should be (once set, never move; if moving, it's a fatal error)

    – those that do a half-arsed version of a constant (can be set only in this or that case; that's the most wrong, because what should be the actual value? That of the last declaration, or should it vary depending on when re-affectations take place in code)

    – those that aim at maximum 'compatibility' without supporting the feature (don't fail on seeing the 'const' declaration, but use the constant as a variable)

    – those that don't implement 'const', and do so consistently: fail on load.

    My take on the regexp: making it slightly more permissive isn't THAT much of a problem. those that want to keep close to the spec, can still write strict ones. There are enough regexp validators out there for that (however, I wouldn't mind a built-in one, or at the very least a console warning saying 'ambiguous character in regular expression' or something – best of both worlds). For now, use JSlint.

    Same thing on conditional function declaration: accepting them is one thing, but I wouldn't mind a console warning ('warning: ambiguous declaration'). For now, use JSlint.

    Otherwise, nice and clear.

  19. Miguel Web Developer says:

    SVG:  59% implemented

    http://www.w3.org/…/20061213

  20. Miguel Web Developer says:

    SVG:  58% implemented

    http://www.w3.org/…/20061213

  21. zzz says:

    I don't believe average IE user gives a toss of these standards. If MS is thinking they'll keep market share by adhering to standards/compat/devstuff and then completely forgetting real world usability & perf of the browser, similarly as happened with Windows Explorer since Vista and IE8 then someone need to wake up there. Who cares about IE standards compat if no one is using IE??? You are wasting ton of money by listening to these web monkeys here. Pay more attention to bugs reported on Connect. Go through all "by design" "won't fix" bugs that affect user experience and if there's more reported during beta, don't RTM until they're all nailed.

  22. digitalwitch says:

    Thanks for the insight into the IE9 team's design process – very illuminating!  As a web application developer I never thought I would find myself excited by a version of Internet Explorer, but I am really looking forward to seeing your final product!

    Another thing to remember about code in the wild is that a lot of it was never written for or tested on multiple browsers.  This can help explain the use of "broken" consensus features (lack-of-consensus features?) such as statement-level function declarations.  As long as it "worked" in the developer's browser of choice and they never bothered to try other browsers with differing implementations, they never would've seen any incompatibility issues.

  23. orcmid says:

    Very useful window into the deliberation process to keep from driving a specification into the weeds.

    I like the notion of consensual features.  The question I am left with is how is anyone to know what those are and who are the confirmed parties to the consensus until (if ever) the specification reflects the consensus?

    Is IE9, for example, supported by implementation notes that call out the consensual features as well as any deviations from, say, ES5?  (I hestitate to ask the same regarding HTML5.)

    Basically, where is the existence for the consensus in something tangible and freely accessible>

  24. giuseppe says:

    what about ES5 strict mode?

  25. giuseppe says:

    What about ES5 strict mode?

  26. Harry Richter says:

    @ Meni

    I guess I AM quick! :-)

    Here is a link to the full press release from mpegla.com: http://www.mpegla.com/…/n-10-08-26.pdf

    I am glad they waited until Google spent money and time, because thus could the biggest threat to the internet and privacy not spend these ressources on finding new ways to spy on me.

    Cheers

    Harry

  27. greggT says:

    I'd much rather prefer that MSFT spend their time and effort adhering to standards strictly than chasing their tails to be compliant with fools' websites.  What, exactly, are your well-formed unit tests?  Where is your formal programming training?

    A little thought experiment: extrapolate out 30 years and imagine trying to maintain code that's compatible with 2010 websites.

    Start by looking back: what if MSFT patched IE6,IE7,IE8 to be compliant with existing standards, however incomplete or ambiguous?  Many corporate browsers still use IE6 (surprise! like our 5000 employee hospital) and have no plans to upgrade because they are not sure that their existing websites will work with newer IEs. So ask yourselves why MSFT has NOT patched those old browsers… I submit it's FOR THE SAME REASON that MSFT will not patch IE9 in 30 years:  It's hard to write and test that code, no corporate customer would dare apply the patches, MSFT rarely publishes technical spec's on what was implemented (to the public) and so it's a waste of everyone's time.  So why is MSFT creating that condition all over again?

    How can you break that cycle?  I suggest, in the strongest terms, that MSFT forget about what websites do wrong — you're already incompatible with lots of them and will never be compatible with some corporate websites based on old browsers — and that will get everyone on the same page.  If you want people to use IE9, make it right, not compatible.  Compatibility is a rat's nest of maintenance headaches and doesn't help force web designers into the proper use of JS.   You'd be making it worse, and how can that help?

    Don't be popular; be right.  Tough love helps everyone.

    Look forward, not back.  Don't make yet another quirk mode.

    And most of all: it saves web designers money, and you get more customers if websites are not designed with "not compatible with IE" signs.

    Be smart.

  28. Aethec says:

    greggT, don't you think that if someone downloaded IE9 and went to his favorite website to discover it is broken in IE9, he/she would uninstall IE9 and go back to what he/she was using before ?

    People don't care about bad code on websites they visit. They want to view the Web. A browser that isn't compatible with existing web sites will never be able to gain any market share.

  29. mitch074 says:

    @greggT, @Aethec: there is a line to walk between strict standards compliance and the quest for perfect backward compatibility.

    The former makes an unusable browser, the latter means sticking with IE 6 (or 7).

    Right now, IE 9 seems to stick to "what other browsers do"; it's not SO difficult, considering that you have two big competing engines (Gecko and Webkit), the second of which was modelled after the first (a looong time ago, when KHTML got written, it was written against Gecko's way of parsing HTML; granted, there's been some differences since then), and a third one that flip-flops between IE and radical standards – with a market share barely above 1%.

    So, one way to make future-looking browsers would be to write them to accept rather wide programming practices, but make developer tools warn when such corners (extended regexp syntax, conditional declaration, use of non-standard keywords…) are cut.

    In short, "be open in what you accept, be strict on what you output". That allows older websites to still work with your product, but it also paves the way for future, stricter websites.

  30. ced says:

    I agree with oliver:

    "In practice, all browsers accept regular expressions such as /]/ and web developers write them. "

    it could be, but it's pointless to avoid them to do it. one of the most cool feature of js implementation on ie is that everything breaks if you put a comma at the end of a literal object ( var a = {prop : 'val', prop1:'val1', } ).

    other browser don't, but I respect this approach.

  31. Would be nice to have more posts highlighting all the inconsistencies you've run into across different engine, since it will help wed devs a lot in order to avoid running into this issues!!

    btw is ie9 going to support ?

    var myObject = {

       get who() {

          return 'I am a getter'

       }

    }

  32. boen_robot says:

    @Irakli Gozalishvili

    That long post had a lot to say about getters and setters, and you still had to ask, didn't you?

    I mean, just read the post… the syntax for getters and setters is not finalized, and was left for future versions of the ECMAScript standard. The MSIE team chose not to implement existing non-final syntaxes, which is a policy I for one can agree with.

  33. giuseppe says:

    @boen_robot

    "That long post had a lot to say about getters and setters, and you still had to ask, didn't you?"

    The notation Irakli Gozalishvili referred to was not mentioned at all.

    "I mean, just read the post…"

    "the syntax for getters and setters is not finalized, and was left for future versions of the ECMAScript standard."

    The post says "The __defineXXX__ methods were left out of the ES5 specification.". Also, the Object.defineProperty/defineProperties/etc methods are in ECMA262 5th edition (15.2.3 Properties of the Object Constructor). And it doesnt read like the __define*__ methods will be in any future EcmaScript standard. I mean, just read the post 😉

    g

  34. Good post. It is REALLY great to hear how much thought is going into your product. Like other comments I always wonder why some things make it and some do not. Good post!

  35. when says:

    When are the developer tools in IE9 going to be fixed? The DOM tree on the left has no horizontal scrollbars (at least when there is a small, but wide DOM) thus making it impossible to use!

    In addition, multiline script tag contents are rendered on 1 line, without any delimiters so the lines bleed together.

    e.g.

    callMethod('baz');

    //special case

    var foo = "bar";

    becomes:

    callMethod('baz');//special casevar foo = "bar";

    since most code is actually dozens of lines this becomes unreadable (esp. when there are no scrollbars!!!!!!!!!!!!!)

  36. EricLaw [MSFT] says:

    <<everything breaks if you put a comma at the end of a literal object ( var a = {prop : 'val', prop1:'val1', } ).>>

    Not in IE9 Standards mode. In legacy modes, you'll get the script error: "SCRIPT1028: Expected identifier, string or number" but in IE9 Standards mode, there is no error.

  37. Matt says:

    > "In addition, multiline script tag contents are rendered on 1 line,

    > without any delimiters so the lines bleed together."

    To debug script, use the SCRIPT tab rather than the HTML tab.

  38. prawnsloth says:

    Just because some websites have incorrectly written javascript doesn't mean a browser should be lax on errors. I cringe every time you say "this would break some websites". Who cares if it would break them? It's a much simpler task to fix a site to be standards compliant than it is to fund a development team to code a browser around current web code. Where is this handful of sites you are afraid to break?

    Failing to escape brackets in regular expressions should be the least of IE's development worries. You guys have failed to support even the most basic CSS specifications for the longest time.

    Internet explorer has become a little more than a tool to download competitors browsers with. As a professional web developer, I really wish you guys would pull yourselves together and /finally/ come through with a proper browser.

  39. Sigh says:

    Troll elsewhere, sloth. You clearly haven't bothered to read anything about how the web browser market actually works (Hint: users uninstall browsers that don't work on the sites they like.) and claims that IE doesn't support "the most basic CSS specifications" indicates that you don't have any clue what you're talking about. IE8 has better support for CSS2.1 (the latest recommendation from the W3C) than any other browser.

    Publishing HTML doesn't make you a "professional web developer". Professionals have enough pride and integrity to post their rants under their own name.

  40. Allen Wirfs-Brock [MSFT] says:

    @Irakli Gozalishvili @ced

    Regarding getter/setter definitions in object literals and trailing commas.  Those are features of ES5 and are supported in IE9 standards mode.   See my previous post about ES5 support in IE9 for details  and a link to the actual ES5 specification. See  blogs.msdn.com/…/enhanced-scripting-in-ie9-ecmascript-5-support-and-more.aspx

    @mitch074

    >> IE 9 seems to stick to "what other browsers do"

    Actually I was trying to say something quite different. We don’t just do what other browsers do. We prefer to have a standard to guide us.  When we don’t  we evaluate each issue in a principled manner as explained in the post. Sometimes the result is that we do “what other browsers do” and sometimes is isn’t. Two of the example I used are for issues where we decided not to do what other browsers currently do.  I chose those specific issues to talk about because I wanted to explain exactly why IE9 is not providing some JavaScript features that exist in other browsers.

    @orcmid

    You’re exactly right.  The big problem with consensus features is that they are not written down anywhere.  Even browser  implementers don’t necessarily know what they all are until the go back and reread 10 year old code.  This is really a failing of the standards creation process.  True consensus features should be incorporated into the appropriate standards.   The consensus regexp extensions probably should have been added to ES5.  However, as far as I can recall nobody suggested it.  Things that are already implemented and work just aren’t thought about a lot.  This is something I hope we can do better in the next edition of the  ECMAScript specification.

    @David Bruant

    >> I think that the correct behavior is to throw an error since an interpreter should help detecting obvious semantic errors and this is clearly one

    The correct semantics isn’t so obvious.  If it was, you wouldn’t see different browsers implementing different semantics for const. Typically there are many possible and plausible semantics for a programming language feature. That’s why standards are important.  They tell implementers which of the many possible alternatives is the one that is supposed to be interoperable with other browsers.

    Allen Wirfs-Brock

  41. Brophy says:

    "How do we decide whether to implement a feature that isn’t included in a standards specification? Like all browser providers, we often have to make this decision."

    Extending this line of reasoning, does this mean you'll be deciding to bundle WebM in IE9 by default?

  42. Clue says:

    <<does this mean you'll be deciding to bundle WebM in IE9 by default>>

    Of course not. Instead, they'll wait for one of their competitors to bundle it (Google, prolly), wait until they distribute a few million copies, and then have MPEG-LA sue for billions.

    The whole codec war is over anyway. With MPEG-LA's announcement of royalty-free streaming for non-pay content forever, WebM is stillborn.

  43. Brophy says:

    "The whole codec war is over anyway. With MPEG-LA's announcement of royalty-free streaming for non-pay content forever, WebM is stillborn."

    Okay. There's not much I can do for you here. It's immensely disappointing that you seem to profoundly misunderstand what the MPEG LA's "announcement" actually means. Whether you're paying for it or not, it is the MPEG LA's contention that no usage of H.264 can occur without the largess of their licencing grace. On the bright side, it is with some considerable amusement that I watch people actually defend the abject absurdity of licencing required for the mere *transmission* of a file over the Internet. It really is quite an astonishing case of Stockholm Syndrome.

  44. Mitch074 says:

    @Allen Wirfs-Brock: I didn't mean that IE copies the other browser (you'd have integrated Webkit's KHTML if that were the case),  but that in cases where practices deviate from the standard in a not-too-dangerous way, you do as other browsers do. Which is not so bad, after all.

    However, I'd really like an answer on my idea of warnings in case of standards-deviating code that is still parsed and run by IE – is it possible? Can it still be implemented? That would be darn useful if built-in.

  45. Kevin says:

    Your first example about the /]/ vs /]/ RE inadequately demonstrates what you want to convey.  First, you admit that the standard specifically says /]/ is illegal, you tell us why, then you imply this is a form of "consensus feature."  You define "consensus feature" as an implemented "feature" that's not part of a standard.  You saying the illegal /]/ (by the standard) is a feature not part of a standard conflicts with itself.

    For this example it's best to note that this broken-ness is ultimately the website implementor's fault for not coding for standards, but also the browser maker's fault for also not implementing the standards.  In this example, neither party followed the standards, and thus both have made this standard worthless.  Implementing /]/ as if it were legal simply because there isn't a matching [ and thus it is parsable is a standards implementation issue and ultimately not relevant.

  46. André R. says:

    >  function declarations anywhere in a statement

    Simple, allow with a notice or warning in console if your running IE9 mode and disallow totally in "use strict"; mode.