ECMAScript 3 and beyond


The web has become the primary global computing platform tying together hundreds of millions of sites. In the eight years since the release of the ECMAScript Language Specification 3rd Edition (ES3), ECMAScript (commonly known as JavaScript™ or JScript ™) has grown in importance as one of the key technologies of the web.


 


The specification of ECMAScript has been stable for eight years. In many ways, this stability was probably an essential enabler for the emergence and broad adoption of Ajax technologies. However, today’s ES3 standard does not capture all the de facto compatibility conventions reached by eight years of this stability – the compatibility so essential to the success of rich web applications. For rich web applications to be successful, JavaScript must function identically on all browsers. The developer of a JavaScript-based web application does not get to choose what implementation will run their application; the user implicitly chooses that when they choose their preferred browser. Strong implementation conformance, then, across browser-based implementations is fundamental.


 


Let me give you a few examples of the lack of such conformance:


Did you know that Custom properties that shadow [[DontEnum]] properties on Object.prototype are not enumerated using for-in in IE? Consequently, it is not possible to transfer them from one object to another using for-in. Consider the following script where toString is shadowed on cowboy.


 


<script>


function cowboy() {


  this.toString = function () { return “cowboy”; }


  this.shoot = function () { return “bang!”; }


}


 


var p = new cowboy();


 


document.write(“Enumerable properties:”);


for (var i in p) {


  document.write(” “, i);


}


 


var res = p.propertyIsEnumerable(“toString”);


document.write(“<br/>propertyIsEnumerable(\”toString\”): “, res);


 


res = p.hasOwnProperty(“toString”)


document.write(“<br/>hasOwnProperty(\”toString\”): “, res);


</script>


 


How about the case where FireFox implements additional properties (and that could cause unexpected results)?


 


<script>


var x = {};


x.__proto__ = 3;


document.write(x.__proto__);


</script>


 


Try these on your browser and see what happens.


 


The point is that JavaScript developers shouldn’t have to detect and workaround such issues. JavaScript should work the same across all implementations. We believe this is the first step in making JavaScript better.


 


To make it possible to achieve such implementation conformance, the first step is knowing where the divergences are. We in the JScript team are looking into where various browser based implementations diverge, where our engine is incorrect in its interpretation of the specification, what if any de facto compatibility conventions have been reached, and the value of codifying such conventions into the standard. We’ve published the first draft of JScript Deviations from ES3 as a starting point.


 


In upcoming posts I will touch briefly on issues that we are looking at keenly and that we hope will make the life of the web programmer easier. If you would like some specific topic covered, please do let us know.


 


– Pratap Lakshman, JScript

Comments (40)

  1. Hi Pratap.

    So you think JavaScript should work consistently across platforms, huh?

    That’s a loaded statement. I mean, this is the JScript blog, right?

    So you want to fix bugs in JScript, but why now? I mean, most of the bugs in your document have been well-known for years.

    You forgot to mention a few:

    -0.7.toFixed(); // What should the answer be?

    http://www.jibbering.com/faq/#FAQ4_6

    Old bug, since IE4.

    "Custom properties that shadow [[DontEnum]] properties on Object.prototype are not enumerated using for-in in IE?"

    That is partially true. There are exceptions to that:

    1) JScript considers a property named "prototype" to be enumerable

    2) JScript considers a function’s instance property "prototype" to be not enumerable.

    ({ prototype : 1 }).propertyIsEnumerable("prototype"); // JScript says true.

    Function().propertyIsEnumerable("prototype");// JScript says false.

    The DontEnum bug is a well-known and reported problem since IE4. It has been reported directly to IE (this can be proven).

    There’s the old FunctionIdentifier bug.

    JScript will leak a FunctionIdentifier

    var x;

    (function initialize(){

     x = function x(){}

    })();

    alert(‘x = ‘+x);

    alert(‘initialize = ‘+ initialize); // Should be undefined.

    The reason x is undefined in IE is JScript will create and bind |x| to the Variable object in the FunctionExpression. Then, |x|, being part of the Variable object, is assigned the value of |x|. The function exits and |x| becomes inaccessible to program code.

    The ECMAScript production for a FunctionExpression is as follows:

                 function Identifier(opt) ( FormalParameterListopt ){ FunctionBody }

    This bug makes it impractical to name a FunctionExpression cross-browser.

    There are many other such JScript(TM) bugs.

    http://blogs.msdn.com/ericlippert/archive/2005/05/04/414684.aspx

    Microsoft has consistently dragged its feet with each release. This persists across to HTML, where BUTTON and LABEL are still not supported, to the uncountable CSS and DOM bugs.

    I remember when IE6 came out, it still did not support position: fixed.

    While other browser vendors have short releases and respond to bug reports, MSIE releases a browser every several years, often with the same well-known bugs that have been carried over from IE4.

    Why Microsoft is gathering feedback on well-known bugs?

    These are old bugs from IE4. Why mention them now? Isn’t it embarrassing? I mean, telling the world, yep, we never fixed all of these bugs in 8 years.

    Why not just fix them and apologize for taking so long?

    "JavaScript developers shouldn’t have to detect and workaround such issues. JavaScript should work the same across all implementations. We believe this is the first step in making JavaScript better."

    These are JScript bugs. Why are you them JavaScript issues. Fixing JScript bugs doesn’t make JavaScript better. This is not semantics, or poor word choice. It is called lying to the public.

    lie: Calling JScript JavaScript

    lie: JScript doesn’t work consistently accross browsers

    Fact: JScript is not JavaScript. It’s far from ECMA-262 compliant

    Fact: JScript only runs in IE.

    Fixing these lies in your statement, your opinion would read:

    "Developers shouldn’t have to detect and workaround JScript bugs. JScript should work. We believe this is the first step in making JScript better."

    How does the truth sound?

    Be honest.

    Trust me, I know they are bugs. I know that they have not been fixed since IE4.

    Your document also mentions that calling delete on a window property throws an error. It does not, however, mention that that error throws an error when you attempt to access the error’s name property:

    typeError.name:

    (function(){

    var isIE = false;

    var bork = 1;

    try{

       var deleted = delete window.bork;

    } catch( e ) {

       isIE = true;

       try {

           alert( e.name ); // IE Actually throws an error on e.name – bad variable name.

       }

       catch(ee) { // IE Actually throws an error here.

           alert( ee.name + ": " + ee.message + " n"  );

       }

    } finally {

       return isIE;

    }

    })();

    Elision bug.

    [ , ]; // length is 2 in IE. Spec clearly states what the production

    for Elision is.

    In fact, a lot of guys ask: "Garrett, why do you put the comma first?"

    {

    a: 1

    ,b : 2

    ,c : 3

    }

    I put the comma first because if it comes after, and I have an extra

    comma at the end of my list, IE will throw an error with the wrong

    diagnostic info. Wrong line number and everything. The MS Script

    Editor will hilite the wrong line, wrong file, usually. When I’m on a

    team, I usually advise others to do this because they will come to me

    when their code doesn’t work and I have to find the dangling comma.

    Putting the comma first is ugly, but I advise this for the sake of having to

    debug wrong messages in IE.

    Just support ES4 with the plugin and it will work. Microsoft has had 8 years to fix these bugs. Embarrassing. Please stop holding back progress.

  2. IEBlog says:

    There have been a number of blog posts recently about JavaScript developments, e.g. Gabriele Renzi’s

  3. Tino Zijdel says:

    Just to set things straight: JavaScript and JScript are both ECMAScript /implementations/. JavaScript is being maintained by the Mozilla Foundation, JScript by Microsoft.

    The example given here with respect to for-in is a JScript behaviour and has nothing to do with JavaScript. If you think that JScript’s behaviour is better in this respect than JavaScript’s behaviour, or if you think that Firefox’ behaviour with respect to the special JavaScript __proto__ property is incorrect I suggest you take it up with the Mozilla Foundation and/or Brendan Eich.

    The mere suggestion that JScript’s behaviour in these cases should be considered the de-facto standard is preposterous.

    And what about these:

    ‘bar'[1] // should yield ‘a’

    ‘bar’.substr(-2) // should yield ‘ar’

    stop lying, start fixing!

  4. Tino Zijdel says:

    And another one:

    /./.test(‘r’)

    IE: true

    Firefox: false

    Opera: false

    Safari: true

  5. Allen Wirfs-Brock says:

    Tino:  I think you misunderstood what Pratap way saying about de-facto standards.  The fact that JScript does something a certain way certainly does not make that a de-facto standard.  However, if all of the major browsers do something the same way, even if what they do is contrary to the actual standard specification, then that common behavior is in fact a de-facto standard.  Understanding where such de-facto agree exists is an important part of standards evolution.

    When there are differences among implementations as in the example in your second comment.  Then that is a place where the standard may need to be clarified.

    Allen Wirfs-Brock

    Microsoft

  6. Pratap Lakshman says:

    Garrett,

    Thank you for pointing out some additional items which we will verify and then incorporate into our document. This sort of feedback is appreciated and is what we were looking for; if you know of other items that you believe should be included please let us know.

    This is not just about "bugs" though. It is about understanding the de facto standard for ECMAScript. In the case of JScript, some of the deviations from the ECMAScript specification are true bugs while others are differences in interpretation of the specification. A whole section in the document is devoted to items that the specification explicitly left undefined. That said, it really doesn’t matter what category an item falls into; if programs depend upon identical behaviour in all browsers it becomes a compatibility issue going forward.

    The emergence of Ajax has certainly increased Microsoft’s appreciation of the importance of ECMAScript on the web and we are investing accordingly. Ajax has raised the compatiblity-bar for ECMAScript and our own services and frameworks would benefit from the existance of such compatibility.

    I am not claiming that JScript is the de facto standard. All I am saying is that before we can hope to improve compatiblity/interoperability among browsers it is essential to understand what has actually been implemented and what de facto agreements exist among the various browser implementations.

    – Pratap Lakshman, JScript

  7. Pratap Lakshman, JScript says:

    Tino,

    Indeed, as your second comment shows, yet another case where the observable behaviour between various implementations differ. Thank you for pointing it out.

  8. EDF says:

    @Pratap Lakshman

    I take issue with some statements here and agree with the other commenters (mostly).

    "The web has become the primary global computing platform tying together hundreds of millions of sites." TRUE

    "In the eight years since the release of the ECMAScript Language Specification 3rd Edition (ES3), ECMAScript (commonly known as JavaScript™ or JScript ™) has grown in importance as one of the key technologies of the web." TRUE

    "The specification of ECMAScript has been stable for eight years. In many ways, this stability was probably an essential enabler for the emergence and broad adoption of Ajax technologies."  FALSE and FALSE

    There’s nothing stable about it.  Evidenced by noone doing a darn thing with AJAX/DHTML until Google put it into their maps.  Now there’s a dozen or more major libraries (free and pay-for) to AJAX-enable sites…  why?  Because there is no stability or cross-platform friendliness.  These libraries try (heavy emphasis) to take the immense pain out of writing in ECMAScript/Javascript/jscript AND in making it compatible across browsers.  Most (including Microsoft) can not support 5 different browsers across 3 different desktop/server platforms – let alone work on mobile platforms.

    As a point of interest, if there is such "stability", why can’t Microsoft get any sites besides their own to work in all 2 year old or newer browsers (desktop and mobile)?  Oh…  even Microsoft can’t do that on their own sites.  Go to them in Opera or Safari and try.  Try using those sites on your Nokia or Palm smartphone.

    I love a lot of Microsoft stuff.  I know you can’t tell from this post, but I do.  What irks people like me is that Microsoft used to innovate – ten years ago.  But since then has crapped all over the web in a dozen ways, and the Jscript "implementation of ECMAScript" is just one of them.  IE5/6/7 is another.  Keep creating posts like this and you’ll find the rest.

    This can’t really be surprising to you guys, is it?  You’ve let us down and this post is too little – too late.  Just drop this "interpretation" and use someone else’s.  Use the Opera or Mozilla or WebKit interpretation…  why do you have to invent the wheel every time, in the process locking in clients on technology that holds back the rapid development the web had 10 years ago?

    I don’t need to list bugs and workarounds…  a couple good yahoo or ask searches should suffice with LOTS of ammo.  Garrett Smith was much too generous…  but it helps with the point.  Fix what’s been known for a long time…  focus on playing nice with others…  not the embrace/extend/extinguish.  Work with  standards and other companies, and be public about that work and about playing nice with others.

    "For rich web applications to be successful, JavaScript must function identically on all browsers."

    -This is absolutely true.

  9. If de facto standards and the actual ES3 spec overlap and differ, please choose the ES3 specifications. The other browser makers will catch up.

    If de facto standards and the proposed ES4 spec differ please choose the ES4 spec.

  10. Tim Cooijmans says:

    EDF,

    The specification being "stable" for eight years means that it has not changed in eight years.  It does refers to the specification (EMCAScript), not the implementations (JavaScript and JScript).

    Other than that, I fail to see how the stability of the specification had much to do with the emergence of AJAX technologies.  XMLHttpRequest is not a part of ECMAScript.

    Tim

  11. anonymous says:

    another way to go, in order to have the best JS implementation is to concentrate in one engine, no ?

  12. BD says:

    While I applaud this new effort in bring JScript into line with the broadly understood interpretations of the ECMAScript Standard, it’s phrases like "de-facto standards" that have me worried: as a web-developer for over 10 years now, I’m fully aware of Microsofts "unique" interpretations of standards, to the point that many people in my industry actually consider Microsoft’s actions as deliberate and an intentional brake on the progress of the web, to this end it can be considered extreemly successful. It’s got so bad that many companies have started the RIA drive to completely side-step the poor implementation of universal access on the web due to IE’s inefficiencies. If Microsofts efforts were to splinter the concept of a web platform (browser) across several competing RIA platforms.

    Back to my original point: when it comes to implementing web standards, including ECMAScript, intent is everything. Were supposed to be working towards a common goal here, and I beleive that this common goal is widly understood.

    Instead of running reports on the current de-facto standard (which is patently an effort to subvert the existing standard by argument of the de-facto standard), why not start a JavaScript Implementation Standards Group to collate all the differing implementations with the JavaScript developers of Mozilla, Opera and WebKit and ammend the ECMAScript standard in the areas where confusion exist? At least then you could all agree on how you SHOULD implement these ambiguous or unclear sections of the standard?

  13. Anon says:

    how about this little gem

    use this little function for shits and giggles.

    function update_box(obj) {

     box = document.getElementById("boxidandinputname");

     box.innerHTML = obj.value;

    }

    then, in the HTML have something like this

    <input name="boxidandinputname" type="text" onchange="update_box(this);" />

    <div id="boxidandinputname">This _SHOULD_ become the value of the input box</div>

    Now the behvior in firefox is accurate, it gets the element BY ID! which turns out to be a div, in IE 7 (and every earlier version I tested), it gets the input element.

    Fix that and I’ll be a little happier. Note "little", because IE has such piss poor javascript handling that it takes up around 15-20% of a project to ensure that the code that works fine in every other browser, actually functions in IE.

  14. anon says:

    And another one;

    if I call an onchange handler on an input element, I don’t want that event to be queued until another event happens.

    For instance, if I set onchange="function(obj);" for text inputs, I’d expect it to be processed immediately rather than _AFTER_ another, unrelated javascript event takes place.

    You know, I could go on for hours harassing you about IE’s javascript handling, but those two should give you some idea what web devs are _REALLY_ up against because of the poor implementation in IE.

    and don’t get me started on the CSS2 handling!

    I’ve always thought of IE as a kind of retard you have to make allowances for. "Oh that’s just jimmy over there, we have to wipe the dribble off his face every once in a while but he seems happy"

  15. Anon2 says:

    "Oh that’s just jimmy over there, we have to wipe the dribble off his face every once in a while but he seems happy"

    Best. Description. For. IE. EVER.

  16. Josh Stodola says:

    It’s good to hear that someone is finally considering fixing these legendary issues.  I fantasize about the day where I will not have to write a 40 line function to accomplish something so trivial.  Only reason it is so many lines is because I am forced to detect which method the browser supports (if any).

    It’s a pain in the ass and I hope it becomes a high priority soon.

  17. Steven Knox says:

    Pratap,

    That document is very helpful information. However, I believe you have the cart before the horse here. Specifically, many of the items in that document (e.g, items 2.3, 2.5, 2.6, et al) are not variant interpretations, but demonstrable incompatibilities with EcmaScript. Also, technically speaking, the "extension" objects like ActiveXObject, FileSystemObject, and (why’d you miss this one — it’s the only MS extension which has actually proved useful?) XMLHTTPRequest are NOT EcmaScript compatibility issues, but host Object-Model compatibility issues.

    Step One should be to fix demonstrable incompatibilites, then to move on to the gray areas of interpretation.

    @anon: the issues you mentioned relate more to DOM-compatibility rather than EcmaScript.

  18. Hello Microsoft JScript team and Mr Lakshman,

    I went (skimmed) over the jscriptdeviationsfromes3.pdf document.

    It’s depressing to see how many differences, incompatibilities there are between major browsers.

    One that is not mentioned in the document. Error object name are often not the same in browsers. When I do a try..catch..finally block and inspect the error object, I am absolutely convinced that an undefined variable should be reported as a ReferenceError, not as a TypeError.

    The Javascript Bible 4th edition (D. Goodman) reports that "Unfortunately, there are some discrepancies as to the specific name supplied to this [name] property for script errors".

    Also, as reported by others (for many years too) but not mentioned in jscriptdeviationsfromes3.pdf, toFixed() for values comprised in the ranges

    {(-0.94,-0.5], [0.5,0.94)} are wrong:

    http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/JavaScriptToFixedSupport.html

    Regards,

    Gérard Talbot

  19. Re: Anon says:

    Anon, those aren’t JS bugs as far as I can see. They’re DOM ones.

  20. nyet says:

    Here’s one that unnerved us in a non-browser project. Run here with WSH but bug repeatable outside that context. IIRC we tested it in rhino script engine & it worked as expected.

    // doesn’t work; finally not processed

    try {

    throw new Error()

    } finally {

    WScript.Echo(‘here, in #finally#’)

    }

    // does; note dummy try/finally around it

    try{

    try {

    throw new Error()

    } finally {

    WScript.Echo(‘here, in #finally#’)

    }

    } finally {}

    I strongly suspect MS knew about it for a long time. Thanks loads.

  21. SWeko says:

    While we’re at it, dismissing bugs as DOM ones and not J(ava)Script issues is just side-stepping the problem.

    Most of my script code has to do some DOM-ing, and if wouldn’t do me much good if the ECMAScript implementations stay stable and reliable, while the DOM changes wildly from platform to platform…

  22. Hello again Microsoft JScript team and Mr Lakshman,

    Wish list:

    – Full compliance with the ECMAScript Language Binding specified in DOM Level 1 so that HTMLElement objects can inherit from Node.prototype

    – correct (or better) error reporting (name property of Error object and message property of Error object) when exceptions are thrown

    – defineGetter and defineSetter support so that it is possible to assign functions to custom properties of HTMLElement objects

    http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters

    – ability to do nested clause blocks

    – Do not change how arguments are defined. arguments should not inherit from Array. arguments should inherit from Object like ES3 says. Just keep it that way.

    – Support for javascript reserved keyword const: I should be able to define constants with the reserved keyword const.

    http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/JSConstKeyword.html

    – comply with RFC 4329: http://www.rfc-editor.org/rfc/rfc4329.txt

    What is unacceptable is that Microsoft does not fix (widely known) wrong, incorrect implementations of ECMAscript in its JScript or that Microsoft takes up to more than 3, 5, 9 years to fix those. It should take a few weeks or a few months, not years.

    Regards,

    Gérard

  23. Many a times, Java Script developers are perplexed by the fact that the same piece of code written by

  24. Sougalana Egami says:

    It’s going to come down to this:  A) Either MS fully supports JS4, fixes their DOM and CSS support, becomes fully compliant, or B) MS stays at their same level of support for JS 3.x, and pushes SL.

    See, MS makes no $ on JS. Why support something when there is no revenue in it. MS could have bled themselves dry supporting every little Tom Dick and Harry operation that somebody thought was important.  Instead, they chose to support that which they could monetize, just like every single other capitalistic coporation in the world.  There is no fault in this.

    However, darn it, that web thing just won’t go away.  Now B.E. is putting the cards on the table for the world to see. If MS goes their own way, (you heard it here first) – they lose the web.  SL is a terrific technology, but I can’t replicate MS Office on the web with it.  I can, however, replicate MS Office with JS4.  MS doesn’t yet know how to monetize MS Office on the web.  They don’t even know if it can be monetized, and that is scary.  IMHO – MS needs to wholeheartadly embrace JS4, and make it the best implementation of the pack, the fastest, the most secure,the most stable, the most widely adopted, etc blah and blah. Otherwise, all those lofty visions of being a big player in the cloud… are pipe dreams.  Without a browser, you ain’t got a seat at the table, and a browser that doesn’t wholeheartadly support JS4, is going down. By the way, anybody realized that FF is now the worlds most popular browser? 35.4% and rising. See http://www.w3schools.com/browsers/browsers_stats.asp. Nuther Q: anybody spose that Google is going to sit around and NOT scrub MS Office after JS 4 comes out and B.E & Co. get a new FF out? So, 2nd 2 last question: Why? Last answer: if MS had implemented everything right (DOM, CSS, JS) then the world of users, and the several million web designers would have been satisfied with IE.  Problem was, IE was a universal dissapointment, and out of the ashes of world-wide dissatisfaction, rose Firefox.  MS shot themselves in the foot.  They are standing at the doorstep again.  Will they shoot themselves in the foot again?  So, will they choose what’s behind Door A, or Door B? B.E. & Co. don’t care if MS decides to support it, or stick their heads in the sand.  The world will have an incredibly powerful, popular, brand spanking new language, based upon the previously most popular poweful language (JS3).  The world will have a killer browser that does everything they want, that has a low entry bar, but can get as complex as you want, and that is free, and not owned/tied to any particular dev platform (think Expression).  And, folks, isn’t that really what we want?  A killer language, a killer browser experience, univeral, cross-platform, and free.  Well, B.E. is ‘da man, and it is going to happen, and desktop centric apps will still be around, but the web is coming in a way that it hasn’t yet.  Someday soon I’ll just plug my laptop into whatever kiosk I happen to be near, and all my data, and a substantial number of my apps, will download and sync with my browser.  I’ll pay $35 sheckels a year, there will be no DLL hell, I’ll never have to update an app again, and life will be good. So, MS… door A, or door B?

    11/2007 Sougalana Egami aka NZ

  25. &#xA0;&#xA0; In their blog, the JScript team at Microsoft is addressing incompatibilities between Microsoft

  26. &#xA0;&#xA0; In their blog, the JScript team at Microsoft is addressing incompatibilities between Microsoft

  27. &amp;#xA0;&amp;#xA0; In their blog, the JScript team at Microsoft is addressing incompatibilities between

  28. nyet says:

    Thanks also for posting some self-serving astroturfing links:

    "Kudos to the JScript team. The haters are quick to slam the IE (and by association the JScript team) for IE’s incompatibilities."

    "It’s hard to be FIRST, be innovative, and do things exactly the same as everyone else."

    "Credit where credit is due!"

    BTW did you ever get round to fixing the garbage collection so it didn’t leak cycles?

  29. If de facto standards and the proposed ES4 spec differ please choose the ES4 spec.

  30. Pratap Lakshman, JScript says:

    @EDF, @Tim: Thanks for clarifying my point. I did mean that it was the specification that was stable.

    @BD: Like I have said earlier, I am not claiming that JScript is the de facto standard.

    When I say "de facto standard" I mean those things that all widely used ECMAScript implementations do exactly the same regardless of whether or not that behaviour conforms to what is actually specified by the ECMAScript Language Specification 3rd Edition.

    Our document is indeed about more than the above. However, by showing where some major implementations are different or identical in their behaviours, it provides insight for understanding what the "de facto standard" actually is.

    And regarding your point about a "JavaScript Implementation Standards Group" – such a group already exists and is called ECMA TC39-TG1 (http://www.ecma-international.org/memento/TC39-TG1.htm).

    @Gérard: Thanks for sharing your wishlist.

  31. LaC says:

    Pratap, in 2.7 you wrote:

    IE: prints "hellohello"

    FF: prints “hello” followed by syntax error (bar is not defined)

    Opera: prints “hello” followed by ReferenceError (Reference to undefined variable: bar)

    Safari: prints “hello”

    In fact, Safari also raises a "ReferenceError: Can’t find variable: bar". To see it, you need to activate the Debug menu (search for "safari windows debug menu") and choose Show JavaScript Console in that menu.

    I haven’t finished reading the document, but it’s possible that other tests were similarly affected.

  32. I do hope you guys get your act together and fully implement the new Javascript proposed standard.

  33. Webdesign says:

    It’s good to hear that someone is finally considering fixing these legendary issues.  I fantasize about the day where I will not have to write a 40 line function to accomplish something so trivial.  Only reason it is so many lines is because I am forced to detect which method the browser supports (if any).

  34. Webhosting says:

    And another one;

    if I call an onchange handler on an input element, I don’t want that event to be queued until another event happens.

    For instance, if I set onchange="function(obj);" for text inputs, I’d expect it to be processed immediately rather than _AFTER_ another, unrelated javascript event takes place.

    You know, I could go on for hours harassing you about IE’s javascript handling, but those two should give you some idea what web devs are _REALLY_ up against because of the poor implementation in IE.

    and don’t get me started on the CSS2 handling!

    I’ve always thought of IE as a kind of retard you have to make allowances for. "Oh that’s just jimmy over there, we have to wipe the dribble off his face every once in a while but he seems happy"

  35. Tweak Vista says:

    EDF,

    The specification being "stable" for eight years means that it has not changed in eight years.  It does refers to the specification (EMCAScript), not the implementations (JavaScript and JScript).

    Other than that, I fail to see how the stability of the specification had much to do with the emergence of AJAX technologies.  XMLHttpRequest is not a part of ECMAScript.

  36. LFERC says:

    Thank you for pointing out some additional items which we will verify and then incorporate into our document. This sort of feedback is appreciated and is what we were looking for; if you know of other items that you believe should be included please let us know.

    This is not just about "bugs" though. It is about understanding the de facto standard for ECMAScript. In the case of JScript, some of the deviations from the ECMAScript specification are true bugs while others are differences in interpretation of the specification. A whole section in the document is devoted to items that the specification explicitly left undefined. That said, it really doesn’t matter what category an item falls into; if programs depend upon identical behaviour in all browsers it becomes a compatibility issue going forward.

    The emergence of Ajax has certainly increased Microsoft’s appreciation of the importance of ECMAScript on the web and we are investing accordingly. Ajax has raised the compatiblity-bar for ECMAScript and our own services and frameworks would benefit from the existance of such compatibility.

    I am not claiming that JScript is the de facto standard. All I am saying is that before we can hope to improve compatiblity/interoperability among browsers it is essential to understand what has actually been implemented and what de facto agreements exist among the various browser implementations.

  37. Tristan says:

    I’m hoping someone can clear this up for me. If I have a script that is defined as;

    <script type="text/javascript" language="JavaScript">

    //some code

    </script>

    Will IE treat this in exactly the same way as if the script had been marked as JScript or does it treat it differently?

  38. JScript Blog says:

    Making developers more productive through the design, development, and debug phases of web application

  39. Scato says:

    Wow, lots of M$ and IE-bashing…

    I bet Pratap’s intentions were good, but I agree: too little too late

    I’m a webdeveloper. I write JS and PHP. I prefer PHP because it runs in a controlled environment. This is because it runs server side. Nothing running client-side will ever have this luxury. Even Flash/AS has it’s client-dependencies (eg relative URL’s). Every compiled application requires installation. This process is also dependent on which client it runs on. This is why we have installation wizards.

    You will never get rid of installation software. You will never get rid of JavaScript cross-browser frameworks.

    This is not an excuse not to fix bugs. M$ is doing a very poor job at this. Fix bugs. Fix them. Don’t tell me they’re a design feature. Fix them.

  40. Smartmil_Toys says:

    Thanks for the post! I've been using this post as a reference as I migrate a couple of libraries to ES6 modules, with Babel targeting CommonJS and AMD.

    I experimented with Babel to determine if `export default …` breaks on circular reference like `module.exports = …` (CommonJS) and `return nonObject;` (AMD). Babel's CommonJS transform generates modules that handle the circular references just fine. Is this part of the spec, or is this an extension by Babel (and possibly others)?