Welcome to MSDN Blogs Sign in | Join | Help

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

Published Monday, October 29, 2007 1:41 PM by don.raman
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: ECMAScript 3 and beyond

Tuesday, October 30, 2007 2:07 AM by Garrett Smith

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.

# ECMAScript 3 and Beyond

Tuesday, October 30, 2007 3:35 PM by IEBlog

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

# re: ECMAScript 3 and beyond

Tuesday, October 30, 2007 7:16 PM by Tino Zijdel

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!

# re: ECMAScript 3 and beyond

Wednesday, October 31, 2007 5:03 AM by Tino Zijdel

And another one:

/./.test('\r')

IE: true

Firefox: false

Opera: false

Safari: true

# re: ECMAScript 3 and beyond

Wednesday, October 31, 2007 1:02 PM by Allen Wirfs-Brock

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

# re: ECMAScript 3 and beyond

Wednesday, October 31, 2007 2:34 PM by Pratap Lakshman

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

# re: ECMAScript 3 and beyond

Wednesday, October 31, 2007 2:45 PM by Pratap Lakshman, JScript

Tino,

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

# re: ECMAScript 3 and beyond

Wednesday, October 31, 2007 6:02 PM by EDF

@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.

# re: ECMAScript 3 and beyond

Wednesday, October 31, 2007 10:49 PM by Peter Michaux

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.

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 6:16 AM by Tim Cooijmans

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

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 8:28 AM by anonymous

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

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 9:51 AM by BD

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?

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 11:32 AM by Anon

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.

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 11:37 AM by anon

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"

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 12:14 PM by Anon2

"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.

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 12:22 PM by Josh Stodola

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.

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 12:42 PM by Steven Knox

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.

# Error object name and toFixed()

Thursday, November 01, 2007 2:59 PM by Gérard Talbot

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

# re: ECMAScript 3 and beyond

Thursday, November 01, 2007 3:40 PM by Re: Anon

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

# try/finally unreliable

Thursday, November 01, 2007 3:44 PM by nyet

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.

# re: ECMAScript 3 and beyond

Friday, November 02, 2007 5:44 AM by SWeko

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...

# ECMAScript 3 wish list

Sunday, November 04, 2007 2:50 PM by Gérard Talbot

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

# Difference in Java Script behavior across browsers

Monday, November 05, 2007 3:24 PM by Gaurav Seth's WebLog

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

# re: ECMAScript 3 and beyond

Monday, November 05, 2007 8:04 PM by Sougalana Egami

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

# Microsoft JScript team addressing ECMA deviations.

Wednesday, November 07, 2007 8:48 AM by Joe On ASP.NET

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

# Microsoft JScript team addressing ECMA deviations.

Wednesday, November 07, 2007 8:49 AM by Joe Stagner - Frustrated by Design !

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

# Microsoft JScript team addressing ECMA deviations.

Wednesday, November 07, 2007 9:12 AM by Noticias externas

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

# re: ECMAScript 3 and beyond

Thursday, November 08, 2007 3:51 PM by nyet

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?

# re: ECMAScript 3 and beyond

Saturday, November 10, 2007 3:01 PM by 环保展览网

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

# re: ECMAScript 3 and beyond

Monday, November 12, 2007 3:44 PM by Pratap Lakshman, JScript

@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.

# re: ECMAScript 3 and beyond

Friday, November 16, 2007 9:49 PM by LaC

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.

# re: ECMAScript 3 and beyond

Thursday, November 22, 2007 10:49 PM by scott schmitz

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

# re: ECMAScript 3 and beyond

Saturday, January 19, 2008 8:29 AM by Webdesign

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).

# re: ECMAScript 3 and beyond

Saturday, January 19, 2008 8:40 AM by Webhosting

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"

# re: ECMAScript 3 and beyond

Saturday, January 19, 2008 8:41 AM by Tweak Vista

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.

# re: ECMAScript 3 and beyond

Saturday, January 19, 2008 8:42 AM by LFERC

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.

# re: ECMAScript 3 and beyond

Thursday, January 31, 2008 9:58 AM by Tristan

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?

# JScript in Internet Explorer 8 Beta 1 for Developers

Wednesday, March 05, 2008 3:54 PM by JScript Blog

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

# re: ECMAScript 3 and beyond

Wednesday, February 04, 2009 5:55 AM by Scato

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.

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker