Chakra: Interoperability Means More Than Just Standards

發行項
08/25/2010

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

Anonymous
August 25, 2010
I guess to Microsoft, interOperaBility means shamelessly stealing Opera's JS engine name.
Anonymous
August 25, 2010
Opera's engine is called Carakan.
Anonymous
August 25, 2010
@blah Uhh, Opera's is called Carakan, and who even cares anyway?
Anonymous
August 25, 2010
The comment has been removed
Anonymous
August 25, 2010
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.
Anonymous
August 25, 2010
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

Anonymous
August 25, 2010
It's good to see that features are being added because it makes sense and not because random people want them added.
Anonymous
August 25, 2010
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.
Anonymous
August 25, 2010
I must say well done then! But i preferred the python-like syntax
Anonymous
August 25, 2010
im agreement with thenonhacker, at the end of the day it will allow web developers to spend more time playing ...ah i mean...innovating
Anonymous
August 25, 2010
@ all Good news: 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
Anonymous
August 25, 2010
"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.
Anonymous
August 25, 2010
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) www.gwilym.com/.../example-1.html
Anonymous
August 25, 2010
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.
Anonymous
August 25, 2010
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.
Anonymous
August 25, 2010
Frank: They don't "fail"-- they didn't try. "Flexbox" is defined by 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.
Anonymous
August 25, 2010
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
Anonymous
August 25, 2010
The comment has been removed
Anonymous
August 26, 2010
SVG: 59% implemented www.w3.org/.../20061213
Anonymous
August 26, 2010
SVG: 58% implemented www.w3.org/.../20061213
Anonymous
August 26, 2010
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.
Anonymous
August 26, 2010
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.
Anonymous
August 26, 2010
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>
Anonymous
August 26, 2010
what about ES5 strict mode?
Anonymous
August 26, 2010
What about ES5 strict mode?
Anonymous
August 26, 2010
@ Meni I guess I AM quick! :-) Here is a link to the full press release from mpegla.com: 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
Anonymous
August 26, 2010
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.
Anonymous
August 26, 2010
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.
Anonymous
August 26, 2010
The comment has been removed
Anonymous
August 26, 2010
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.
Anonymous
August 26, 2010
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' } }
Anonymous
August 26, 2010
@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.
Anonymous
August 26, 2010
@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
Anonymous
August 26, 2010
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!
Anonymous
August 26, 2010
The comment has been removed
Anonymous
August 26, 2010
<<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.
Anonymous
August 26, 2010
The comment has been removed
Anonymous
August 27, 2010
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.
Anonymous
August 27, 2010
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.
Anonymous
August 27, 2010
@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
Anonymous
August 27, 2010
The comment has been removed
Anonymous
August 28, 2010
<<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.
Anonymous
August 28, 2010
"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.
Anonymous
August 28, 2010
@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.
Anonymous
August 31, 2010
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.
Anonymous
August 31, 2010
> 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.
Anonymous
August 31, 2010
@André R.: +1
Anonymous
September 01, 2010
haha

共用方式為