ECMAScript 3 and Beyond

There have been a number of blog posts recently about JavaScript developments, e.g. Gabriele Renzi’s "ECMAScript 4, the fourth system syndrome". For ECMAScript, we here on the IE team certainly believe that thoughtful evolution is the right way to go; as I've frequently spoken about publicly, compatibility with the current web ecosystem - not "breaking the Web" - is something we take very seriously. In our opinion, a revolution in ECMAScript would be best done with an entirely new language, so we could continue supporting existing users as well as freeing the new language from constraints (including the constraint of performantly supporting scripts written in the old language). My colleague Pratap (our representative on the ECMAScript Technical Committee) with the JScript team, just posted on their blog about some work they've done on this topic. We're also very interested in feedback from JavaScript web and framework developers on their thoughts about their needs and the future of the language.

A cursory look suggests that it is an over-engineered system. It almost looks like it wants to be a complete solutions platform.

THey already have that, it is called Java – why reinvent the wheel?

Does the internet need that level of scripting, or perhaps more appropriately, should any SCRIPTING be that complex? Without a compiler, all that functionality comes at a very high price. Add in a compiler and the flexibility the current scripting has is lost.

(one of my favourite ways to avoid ads and intellitxt nonsense is to block sites that provide the .js files. THis works in a scripting world, but would fail utterly in a compiled world – you need everything).

I can’t see this as anything but slow and fragile.

Personally, I suspect that if people REALLY need more than is currently offered, platforms like Flash and Silverlight are more suitable.

I’ll go one step further and say that as things continue to evolve, HTML & HTTP as we know them will eventually go the way of gopher and telnet (someone still uses them somewhere, I’m sure). The next big thing is just waiting for someone to express it. Once that happens, all bets are off – in the mean time why break what already works?

I’m not sure where "2 years ahead" comes from. Note that the Javascript language implementation and runtime, and the IE object model (including DOM L1/2 P/M/E) are separate beasts. The DOM is specified by the W3C DOM specs, not the ECMAScript language specification.

Xepol talks about Java while ECMAScript 4th Edition is closer to Python than Java and it’s absolutely a good proposal / language that’s more modern than Java too.

IEBlog says:

"We’re also very interested in feedback from JavaScript web and framework developers on their thoughts about their needs and the future of the language."

The future of the language? It’s in front of You, its name is JS2 … not JScript without constants, addEventListner, fake implementations and every other un-standard methods/properties.

Microsoft developers changed C# 3 times in 5 years and You’re telling us that JavaScript should never change because it should break compatibility?

You, that created IE7 warning everyone about CSS hacks? You that have the oldest ECMAScript 3rd Edition implementation?

It’s too simple guys … "don’t swith to ECMAScript 4 because We’ll never implement that, We just have problems with 3rd edition one …"

Imho, if every Web developer will start to write site usable only with JS2 compatible browsers your IE will loose more users than ever … starting from usage: from 90% to 75% or less in about 2 Years!

This is my opinion: as Adobe updated its Flash Player every 2 years and users downloaded them, every Web surfer should upgrade its browser switching them to developers who care about security, language enanchment, bug fixes and every other new cool stuff inside ECMAScript 4th edition that should make Web faster and more powerful than ever.

JScript isn’t even ECMAScript compliant, let alone JavaScript compliant. The linked blog-entry is suggesting that some JavaScript behaviours in other browsers are actually bugs and that JScript’s behaviour in these cases is better.

Well, if Microsoft thinks so I guess they will have to contact the Mozilla Foundation since they are maintaining JavaScript…

I’m, personally, shocked that Jscript or Javascript even gets mentioned here. A year and a half ago, Jscript was a mothballed project attached to a team that was focused on other projects (because someone had to do security work on it).

Chris, are you saying that there is an actual Jscript (or "Scripting in Windows and Browsers", if you prefer) team at Microsoft again? I’m not purposefully yanking anyone’s chain here, I really am surprised by the implication that *anything* is being done in regards to Javascript at Microsoft. It’s been dead there forever.

Can we get a list of reasons why IE wouldn’t want to support the new rev of Javacript that has some details? I’m not sure what the plans of every browser vendor are but I know that there is quite a bit of excitement (and occasional controversy) in the idea that the language is moving forward.

Al

P.S. Can someone please post about IE8? I only ask once a month or so. 🙂

"For ECMAScript, we here on the IE team certainly believe that thoughtful evolution is the right way to go; as I’ve frequently spoken about publicly, compatibility with the current web ecosystem – not "breaking the Web" – is something we take very seriously."

This seems to imply that es4 is not compatible with ES3. Is that what you mean to say? The second sentence of the es4 whitepaper starts with "ES4 is compatible with ES3…" Section III details compatibility starting with "The goal of TG1 is that ES4 will be backward compatible with ES3 and that ES4 implementations will be able to run ES3 programs correctly. This goal has been met, with a small number of qualifications. " The fifth paragraph of that section says "Behavioral changes in ES4 are the result of specifying behavior more precisely than in ES3 (thus reducing the scope for variation among implementations)" which is I believe what you are advocating here in terms of converging implementations.

So if you are raising specific concerns about es4 "breaking the web" can you please elaborate?

Or are you arguing that no backward-compatible additions should be allowed to the language? C# 2.0 added generics, generators with yield, closures, covariance and contravariance for delegates, Coalesce operator, etc. 3.0 adds "features inspired by functional programming languages such as Haskell and ML. (to quote wikipedia). Why didn’t that occur in a new language instead of as a new version of C#? Why is it appropriate to add new stuff to C#, Java, Python, etc but not JS?

I would honestly have two comments to make here. First, IE’s implementation of ECMAScript (or whatever you wish to call it) really ought to support the full specification (de facto or otherwise) that other major browsers do.

But more long-term, I feel that we need to take a serious look at what the web IS. ECMAScript allowed a limited degree of dynamic interaction to be introduced to a previously static web. And that’s OK for what I would term "typical" websites. But at the same time, web "applications" are ever more popular. I think that’s in important distinction to make: browing the websites for information and interacting with actual applications are two fundamentally different activities (though they can intersect at times). Similarly, they are best facilitated through two separate approaches to development.

No matter how you view it, ECMAScript (or any evolved form of it) simply doesn’t cut it. In addition to the lack of fundametal language/runtime-level features (strong typing, multi-threading, "real" object-oriented features, etc.), it’s missing key library-level functionality such as a full range of common data structures, graphics/drawing capabilitis, the full range of UI controls, socket programming, etc. As many have pointed out here, both .NET and Java are excellent implementations that support portability, sandboxing, and power really neccesary to deliver applications distributed across client and server components.

Please don’t screw over the next generation of serious web applications by introducing another "half-way" language. Keep ECMAScript around for legacy sites, hobbyist development, and quick-n-dirty or limited dynamic functionality. But don’t force web applications to use a scripting language that won’t meet today’s (or tomorrow’s) needs. I believe it is very possible to achieve this without sacrificing the "spirit" of the web.

What we need most regarding JavaScript in IE is a clear statement of Microsoft, which way you will go.

There is nothing more annoying than uncertainty.

We just need something we can plan with. If Microsoft decides not to update JavaScript in IE I would like to know it so I can plan with it. If Microsoft plans to update their JavaScript implementation I would like to know this as well.

Personally I’m not that excited about ES4 but what I really would like to see are the newer additions to JavaScript like the generator stuff in JS1.7 or E4X. If I knew this will be supported by IE in a timely manner I may start using this right away and wait for MS to catch up.

I’m not gonna touch the ES3/ES4 thing. That’ll get settled in other fora. What’s deeply, truly loathsome about the current state of the art is how amazingly set-in-stone it appears to be, despite the pluggable architecture of WSH. We haven’t had anything more than cursory patches to JScript in *more than half a decade*. IE7 was nearly silent on the point. The half-assed GC fixes were nice, but we both know that the whole "sweep the tree on unload" (thereby missing potentially latent nodes in the JS namespace but not attached to the document) and the "don’t trigger GC after 1k attributes" fix weren’t rocket science.

You could ship a new JScript to everyone on every version of IE independently of the browser (as you have in the past), but so far there hasn’t been so much as a public discussion about shiping anything new at any date with any feature set. As a previous commenter more eloquently noted, it’s the uncertainty that sucks most.

But the uncertainty sits at the top of a long list (even when the list is constrained just to JScript). For instance:

* getters and setters. It’s a critical flaw in the basic design of the standardized ES3 which most sane implementations of the have already fixed. Why hasn’t JScript? And when will it be fixed?

* Array can’t be subclassed in a meaningful way. This is, to put it mildly, insane.

* JScript blows up on trailing commas in object literals. Gazillions of man hours are wasted on this worldwide.

Most of what’s odious about the Microsoft browser story sits at the boundary between JScript and Trident, but getters/setters and some basic performance work would make a world of difference on their own. The only thing better than knowing that they’ll be fixed is knowing when.

Why in the world are you saying this now. ES4 has been in development for forever now. Theres already a reference implementation written, and half of the other browsers out there have implemented large parts of it. And just now, when everything is said and done , the stardards are set, people are working on real complete implementations, just now you decide to speak up and say, "We don’t like this. We’re going to make something else instead?" and then sit back shocked and appalled when people are kinda miffed.

You should have spoken up a year ago. Luckily, Mozilla is working on writing your ES4 implementation for you and fixing your ES3 one, so regardless of what you do people can keep working.

1) If you’re going to violate your old Microsoft NDA, at least be correct. No, JScript was not on mothballs a year ago, and it certainly isn’t now. Go check out the JScript team blog.

@Mike Schroepfer:

See my blog post in response to Dean.

@Frank:

From your mouth to God’s ears.

@Fabian Jakobs:

We are updating our Javascript implementation, yes, and get (and follow) a clear interoperable standard.

@Alex Russell:

Thanks for the feedback, more on your list later. Please do, though, touch the ES4 issue. Not here; where it matters. No matter what you think. As I said in the HTML WG IRC channel yesterday, "the more people say they’re doing a technical review of ES4 and will form and make their opinions known, the happier I’ll be."

@Dave:

umm, no. The language runtime and the library of functionality available to it are typically somewhat orthogonal.

DigDug:

"Half of the other browsers have implemented large parts of it?" "The standards are set?"

I’m not saying "we’re going to make something else instead," anyway. That’s not my job. And a year ago, I was shipping IE7. That was important too. And take a look at @Steve’s feedback, and others like it.

I’m somehow violating my NDA from Microsoft for mentioning that fact that everyone knew that the scripting engines, as a project, only "lived" inasmuch as someone needed to own them to fix security issues? That’s a stretch. I’d love for you to explain the nuances of how mentioning this somehow violates my NDA from my time at Microsoft in any respect. Sounds like FUD to me.

The fact of the matter is that I didn’t say a "year" ago. I said a "year and a half" because it was almost exactly a year and a half ago that I left the IE team. I have no idea what has happened since though it looks like the work has been shipped off to MS Campus in India based on the new blog (which is, what, six months old?).

Before I left, there had been no work on improving Jscript in years beyond the tiny amount that happened during IE7. Call me a liar on this, please.

While I pick on the IE team for a lack of openness and poor communication, especially since Dave, Scott, and I have left, I generally try to do it with a smile because I know so many of you and like most of you. Please try to return the spirit and not make it nasty in tone or did I just miss your smiley at the end? 🙂

@Dan – <em>And would you please let us pass additional arguments to setInterval and setTimout?</em>

I fixed both some month ago (my blog) and the hilarious thing is that to fix them You need to use an IE bug (ooops … do You prefere to call them feature?) 😀

"<blockquote>Please note that usage of window.setTimeout, instead of direct setTimeout assignment is a must, because if You remove window from left side IE will tell You that operation is not valid while if You remove window from righ side, IE simply will never do anything with those two functions.</blockquote>"

For the viewing readership, "violating" my NDA, seems to largely consist of speaking as a former Microsoft insider who worked on four versions of IE. Chris is of the opinion that if I wasn’t allowed to say something in public a year and a half ago when I worked at Microsoft, I still cannot say it now, so I believe he’s referencing my comments about the Scripting team at Microsoft.

I will keep this in mind in the future but I still think this seems like a fairly petty (and arguable) example, along with the one you made about my post on my blog about the demise of MS Connect. It is pretty common knowledge, for example, that the IE team was broken up after Windows XP shipped for several years. Do I violate my NDA by stating something that people outside MS already know, just not officially?

Maybe I need to make a "Fake Dean Hachamovitch" blog and be anonymous when posting comments on my blog about the state of IE.

MSFT would be wise to start concentrating more on engineering than FUD. By not subscribing to ES4 or cooperatively helping to evolve it, etc it seems to me to be yet another bad decision leading to their continued demise in the browser space. Good riddance, the way it’s been going. They have continued to clearly demonstrate they are not interested in what is best for the web or consumers. Quite the contrary. (FF has 35% market share and rising)

I have just about given up on you guys. Too little, too late. I get our friends and family to use anything else. I’m not the only one and it’s showing, isn’t it? Isn’t firefox and opera market share increasing? Isn’t safari about to come out on Windows? Isn’t IE mobile on the decline?

When is the wake-up call going to be heard? IE7? Too little, too late. It had competitive features 4-5 years ago. It still can’t work with some basic standards that could have been cool to see on the web and we have seen for months/years in other browsers. Part of this is due to your "ECMAScript interpretation". Part of it is a lot of other stuff.

I am disappointed. I want you to play nice with others. Use standards – someone else’s if you have to. Respect the standards boards you are a member of. Add features that make things competitive. I’m not even asking for you to innovate anymore. Leave that to others. Just for the love of God stop writing your own "interpretation" of things that don’t work in other browsers, have less features than other browsers (and on other platforms). Think about the mobile web (and not just ie mobile). Just be a good web citizen.

Acknowledge that there are problems you have created, and will rapidly show a great effort to fix and support an innovative web.

Everyone is waiting to like Microsoft again. To stand in line for Windows 95/IE3, install Netscape and explore the web. You innovated and fixed… and in less than 3 years, released Windows 98/IE4 and innovated past Netscape. What’s happened since then for the browser and web technology?

.Net – but that’s server side, not client side. Silverlight – which has a lot of promise (if moonlight and mobile platforms work well), and is client side, but was released only this year. If history is any indicator, you’ll mess that up too.

It takes so much energy to rant. It really does. I hope you guys can see the passion that I WANT to have about Microsoft’s web stuff. IE and JScript are large parts of that. But for me, I have lost faith. And in a popular polarizing view, if you aren’t a hero, you’re a villian.

Wasn’t JavaScript just a Netscape/Sun front of LiveScript? Wasn’t it supposed to compete as a server platform as well? Didn’t they pose legal threats to MSFT? That’s why MSFT reverse-engineered the JScript bastard, right? And we are supposed to find hope in a European standard?

Fact is, MSFT’s browser sabbatical was the best thing to happen to the web. The last thing I want to see is a bunch of Adobe Flex lobbyists and Silverlight PACs ear-marking ES4 under the guise of "standards."

It took 5 years before Mozilla, Webkit, and Opera figured out how to co-opt XHR from MSFT. Take it as a sign of good faith that the IE7 team made their invention conform to an a-posterior standard.

Take this focus on ES3 standardization as another sign of good faith. If MSFT doesn’t innovate, the rest of the browsers won’t have to waste years catching up and then retroactively declare a "standard," and browser politics can stay out of the creative process.

I’ll take a faster, more reliable ES3 over the "promise" of ES4 any day.

Except the rest of the browsers will be implementing ES4 and web developers are going to be forced to choose again whether they want to restrict what they develop based on Microsoft’s support or lack of support for a technology or standard or to just go ahead and continue to try to move people off of IE. I expect it is going to wind up as the latter.

I thought that’s what had been going on for the last while with ECMAScript 4, Chris. That’s kind of the point of a standard and a standards process. Microsoft may not get entirely what it wants out of it but it has a say, just like anyone else. The question is whether, after you have your say, if you’ll implement the resulting standard or not.

You know what would be funny. If roles were reversed. I remember Apple being the little kid that tagged behind Microsoft’s great achievements in development and the wide variety of applications. Heck, up until a few years ago, Apple ran IE. Now, it seems, Apple is the innovator. Maybe, Microsoft (and IE specifically) should tuck their tail between their legs and switch to Safari or a Webkit-based engine for IE. That would fix a lot of problems that exist in IE’s rendering engine. Apparently the old one is not being fixed for a reason, so switch it out. Some would say Gecko would be a better option, but looking at the codebase, I would disagree. Webkit is cleaner and leaner and has more potential in my opinion. Either way, the time has come for change or application demise.

Can someone give me one ‘thing’ that can’t be done in ES3 that can in ES4? I’m not talking about making things easier. I’m talking about actually producing something different, like XMLHTTP gave us (of course, this could be done with IFrames).

Until then, I think the millions of ‘average’ programmers would rather just have the bugs worked out.

Fprget new languages or evolving the underused old ones, we have enough new stuff on the web. Instead I suggest effort is put into releasing a browser that supports the standards and actually helps move things forward instead of holding them back. Both FF and IE fall short of the ideal in different ways. FF is starting to gain ground due to their momentum in developing quick fixes and moving the browser forward.

IE 7 was better than 6 but nowhere near good enough to be the revolution we all hoped it would be.

The browser war is going to be one of those eternal things that will feed discussion, debate and argument as long as the internet remains.

All we ask, as web developers and users is that someone please for God’s sake just stop arguing the toss and put out a browser that solves problems instead of creating them!

In the 10+ years I’ve been doing web development, limitations of ECMAScript/Javascript have ALMOST NEVER (99.9% of the time) been an issue. My obstacles have usually been browser implementation of existing standards — or rather, the lack thereof.

I suspect that the IE team and Microsoft in general will be facing an increasingly hostile crowd when it comes to web standards. Your company’s silence on its future direction leaves many of us with the impression that IE will (once again) be abandoned.

IE has the lion’s share of users right now: by not focusing on the LONG-EXISTING STANDARDS Microsoft doesn’t "break the web": it merely causes it to stagnate.

Everything else at this point is like debating about what color you’re going to paint your personal space station, or spending your winnings before even playing the lottery.

Stop these token "rah rah, we’re still alive" blog posts and start making some substantial announcements.

@Jason: clearly, Javascript runtime was not a major focus in IE7. We fixed some garbage collection problems, and a few other relatively scoped issues. Our focus was on CSS layout improvement, and to a much lesser degree object model/ajax apis (such as the native XHR object). I don’t think I claimed otherwise?

@Jason: Platform stagnation is good. It has fostered this latest round of web creativity. Platform dynamism is what will send creators running to closed environments like silverlight, flex, or back to the JVM. Not the other way around.

I for one am glad to see some refocus on how well *everyone* implements current standards. There is a wealth of IE discussion out there for ES3 bugs, but if you’re problem is with Opera/Wii, there’s silence. It’s most telling when web standards champions end up posting 1997-style "There is a bug in Safari 1.2" disclaimers. Standardistas seem to be blind to the land-grabbing and treasure-hoarding of their pet browser-maker, even at the cost of their much bally-hooed goal. One web, right?

If IE screws up, I’m fairly confident that it’s being discussed if not solved by someone somewhere. Opera, Safari, now AIR? They’re most-likely the bugs that will blind-side development. ES3 deviations are the right thing to focus on right now.

"@Cal Jacobson: focusing on the LONG-EXISTING STANDARDS is precisely what the IE team has been doing for, oh, the past three years."

My choice of the word "focusing" was poor. What I *meant* (and should have written) was *implementing*.

IE7 does not fully implement CSS2, a standard that has been out since 1998.

"Focusing" (and again, I admit, the choice of the term was mine) is a weasel word, since one can focus on something all day and not accomplish a thing.

I didn’t come here eager to throw stones, Chris — but there are a LOT of technical folks out there (many far more talented than I) who are less than thrilled with the pace at which Microsoft has moved and the priorities it has chosen.

More specifically, *I* am unhappy with the lack of communication out of Microsoft regarding the future of Internet Explorer. If I were a betting man, I’d say Microsoft plans on a repeat of its post-IE6 performance from 2001-2004…that is, very little in the way of innovation or even evolution.

I *hope* I’m wrong. But I haven’t heard anything concrete to the contrary, and for the live of me I can’t figure out why IE8 is such a friggin’ state secret when the other browser developers work out in the open.

Chris, I understand what you mean to say when you talk about "breaking the Web." And it’s a convenient shorthand for the IE team’s self-imposed requirement of 100% backwards compatibility for the next version of IE.

But it’s starting to feel like a talking point — like "support the troops" — that only serves to polarize. Though I’m sure it’s not your intent, the phrase suggests that the answers are clear-cut — that there’s no room for disagreement among smart people about what will "break" the web and what won’t.

The IE team’s definition of a "broken" Web is similar to, but not wholly compatible with, *my* definition of a "broken" Web. I don’t speak for others, but I sense this is a source of conflict between IE and many web designers and developers.

If you are knowingly, using a broken implementation of a JavaScript method, because IE *magically* works this way — STOP! Fix your code to use follow the specs now.

(e.g. if you are depending on a "named" element being returned when you call .getElementById(id) )

IE may bend over backwards to support you in the near term, but don’t count on it long term.

Step 2.) (to be done, while step 1 is in progress) Define the opt-in proceedure, for IE(next) to ensure that .getElementById(id) does in fact _ONLY_ return elements with a matching id attribute! (only by id, and CAse-SEnsITivE!)

Step 3.) Release IE(next) and watch the complaints for IE turn into praise.

Personally I’m not that excited about ES4 but what I really would like to see are the newer additions to JavaScript like the generator stuff in JS1.7 or E4X. If I knew this will be supported by IE in a timely manner I may start using this right away and wait for MS to catch up.

Well, SVG is out of the question due to limited XML parsing abilities, right?

Continuing with CSS compliance, including some CSS3 modules (multiple background-images, anyone? Oooh, and even calc()!), seems to me to be a solid goal for further IE development. Web developers/designers would go nuts, I’m sure. 🙂

If IE will implement ES4 as described in the spec preview I’ve read, I, as a JS developer, would applause. I do not care much if I would have to opt-in my script to be ES4 — as long as my opted-out scripts will function.

Alternative languages are good — IronPython, IronRuby, JScript.NET, whatever. But ES is a must. Because it is a standard, and it is much easy to have a wide adoption of a single standard language than of a number of them.

Also, personally, I think that ES4 is one the most interesting and promising programming languages I have seen in the latest time. It has some features I wanted from C# for years. It would be great if ES4 gained widespread adoption. Does your new language have such a beautiful operator overloading model and does it have multimethods? If it doesn’t, sorry, I would vote for ES4.

"Define the opt-in proceedure, for IE(next) to ensure that .getElementById(id) does in fact _ONLY_ return elements with a matching id attribute! (only by id, and CAse-SEnsITivE!)"

They already said they’re not going to do that (it would break code on the web, and it appears Microsoft values compatibility – seems like keeping things "working" is more important than appeasing whiners). I do not know why people keep going after this particular thing, but I *NEVER* run into this problem at my job. Of course, I typically give form elements the same value for their CLASS and ID attributes (since the LABEL tag FOR attribute expects an ID, not a NAME, and wrapping the control inside the LABEL tag does not always work – and for people who do not know what a LABEL tag is and develop pages with any sort of form elements, "thanks" for not valuing accessibility).

Please implement Live Bookmarks (RSS) if you guys can in IE8 (regardless of the UI problems menus have, they’re good for displaying a list of headlines!). It’s one of those gotta-have features for me that keeps me from using your browser when I am not at work.

The point I’d like to make is that the web *is* broken! Google: 36 HTML errors, Yahoo: 34, Live.com: 66 (MSN’s home page has no errors though and kudos on that). I blame all browsers for supporting crap non-code "code". Why is it that software developers can’t get away with missing a single semi-colon but big corporate websites can have dozens if not hundreds of clientside errors just in their HTML code alone? That’s not backwards compatibility, that’s sacrilege! That’s why I can’t make a living on clientside alone. I am not saying this is what you’re trying to do (this part isn’t aimed at MS/IE team specifically). Microsoft setup proprietary stuff to compete with Netscape at the time, fair enough. @ Chris…I remember hearing a podcast of you in an interview mentioning a third opt-in rendering mode. Could you please elaborate to at least the point where we know if we’ll get both reasonable standards and the all-or-nothing backwards compatibility between two rendering modes? I and thousands of other legit web designers would love to replace incompetent web developers who for who knows what reason are being forced to do clientside code when it’s serverside code they love and would prefer to work on would appreciate being considered for employment for doing what no one else does competently: valid, standard, accessible clientside code. If you guys are adding a third rendering mode in addition to a separate backwards compatible mode you can earn back a lot of love by decimating pages that somehow opted in to break like they should! I’m not knocking web developers (serverside) but the people who tell them to work on clientside for any reason. It would be nice if businesses took professional web designers seriously and again I blame all browser vendors for supporting crap code. Being not-biased as much as possible I’m updating my own site in a couple of weeks which will work just fine in IE4 with minimal patching with pure CSS liquid. You guys are very capable when you are fighting an uphill (market share) battle.

At heart I ultimately want IE and the IE team to succeed. Firefox’s market gains got you guys working on IE again (more or less) and I suspect it is the higher ups who decide what project you guys work on. Whoever it is let them know that until IE is on par with other browsers I will recommend IE users switch to other browsers…though once IE is on par I’d be more then happy to recommend merely updating to the newest version of IE as it’s clear market share is what drives the development of IE regardless of who decides it. I’ve been working with IE4 and (I admit to hardly being anything of a developer so much as a (clientside) designer but when you guys were battling uphill you did some really great stuff. IE4 has very solid CSS1 liquid support (Opera 4 too)…you guys came up with some cool stuff like XMLHttpRequest and favicons. As an semi-entry to average JavaScript developer I’m not advanced enough to truly complain about JavaScript/JScript though from what others are saying I would have to lean towards enhancing current standards and on spare time working towards partial support for stuff like ECMA Script 4 if everything else is truly caught up. Like I’ve said before fix and add things that we’ll love (not err…dislike) you guys for in the upcoming years. With CSS3 that’s rounded corners, multiple background image support, standards based opacity, etc. I’ll leave it to others who clearly have already done so to point out JavaScript related stuff.

I have a general AJAX question for anyone who would be kind enough to help me out. I am using an AJAX ‘includes’ script that loads a file’s contents in to an element by it’s ID. This can be seen on my jabcreations.net website when you click at the top right on "site options" for example. My question specifically is how can I interact with content added by AJAX and give an element by it’s ID focus? Every forum I post on people keep ignoring the fact that the element I want to give focus isn’t accessible via JavaScript the normal way as if it were on the page with the initial load. It just is not working for me and the script is the last of several on the page starting on the line with the comment…

NO! For the love of humanity anything but Webkit for IE’s rendering engine! Imagine the pain every web designer would have to endure every time their boss complained their entire website’s text was bold! If the API or whatever Webkit uses allowed normal font-weight I’d still hold back on such a suggestion, they only recently fixed the noscript bug and they still don’t have anyone working on tabindex…

"I typically give form elements the same value for their CLASS and ID attributes"

That should have been NAME and ID (they’re only uppercase so they stand out – I do not write my HTML uppercase)

"The point I’d like to make is that the web *is* broken! Google: 36 HTML errors, Yahoo: 34, Live.com: 66 (MSN’s home page has no errors though and kudos on that). I blame all browsers for supporting crap non-code "code". "

That is not going to change. People expect things to work (they demand it, actually). If you change browsers to enforce things like type attributes on style and script tags, Google would indeed break (and it’s fairly obvious why they did the page the way they did, considering how much traffic they deal with). I do get a kick out of the fact they’re using NOBR (pretty sure this Netscape tag was never part of *ANY* HTML standard), FONT, and CENTER.

This is vital not to break the web for many people. Refactoring a full web site at once is a real pain. But there is a lot that can be done to help transitioning from old behaviors to more standard ones. For example, let’s take the IE developers toolbar: why not making it installed with IE by default? I mean lots of developers don’t even know the existence of this toolbar. Why not making an error console such what is done in other browsers, and making this console available by default (As opposed to Jscript debugger popup windows that in many case are totally useless –including bugs in Jscript loops making popup windows invading your screen-). Therefore, deprecated features and old behaviors could be warned as being deprecated but could still be processed in a compatible way. Of course every warning could be associated with a good documentation on how to make things more standard and how to avoid unclear parts of the standards. I know that W3C is providing pages to validate HTML / CSS but this is far not enough and cannot apply on some websites that are not publicly available. The idea here is to make developers aware of the wrong coding practices even if the final user is still seeing the same result in his web browser. Making developers exactly easily see what they are doing and what the implications in IE are is in my opinion the first step to make things better. I don’t think you can use external tools here either, because these tools will never exactly process things the way IE is doing so the comprehension of some problems will not always be easy.

The second point is I think making a very well defined line between old behaviors and standard ones. Keeping old behaviors intact is important for not breaking the web but correcting standard features as soon as possible is more than vital since the more you are waiting to make the correction, the more workarounds will appear over the net and the more difficult it will be to make things properly and not break things again. Updates (I mean here bug correction) on IE should be based on a far more regular time basis.

Why not making a well known bug-list integrated in IE that could trigger warnings and deprecate features / methods in the error console as bugs are discovered over time. This bug-list could be updated regularly so you wouldn’t even have to change the underlying IE code? This bug-list could also be standard across IE browsers so it would still be updated even if the browser code is not in production anymore. I think informing people of the right and wrong practices is the half way to making the web better! A well informed developer is a better developer.

The last thing is: IE7 can be installed on Windows XP SP2 and later and WPF can also be installed on Windows XP SP2 and later. Why then, not making future IE rendering engine use this API and make the "hasLayout" feature a thing of the past?

Chris you have made the claim that there is a backwards compatibility problem that would "break the web", but even after all the talk about this just over the last few days, I and so many others are still wondering what that would be.

Any Flash or Flex developer, that has been working with Actionscript 3 for any reasonable length of time, has a perfectly good feel for what the transition from ES3 to ES4 as an upgrade would be like (any small differences between AS3 and the current state of ES4 considered). The fact is, it wouldn’t be that big of a deal. This should be a settled point.

I’m not hearing any specific arguments in terms any security concerns either, which as someone who does much more server side work, to me is a matter of implementation. Frankly the overwhelming opinion seems to be, that the IE implementation leaves a lot to be desired.

I also understand setting reasonable development goals, but if David Hyatt can nearly single handedly fix Safari to pass the ACID 2 test, in the course of a few months, then it seems to me that there must be something wrong with the IE team’s method of development, that adversely affects productivity. You guys have had a LOT of time to work on a lot of this.

As a professional web developer, I’m glad to see that the IE team is finally concerned with not “breaking the web”. The rest of the world caught up with that idea about five years ago: welcome to the party.

As at least one other person has suggested, do the switch based on the MIME type. It’s simple, it’s easy, and anybody who wants the new features will be smart enough to read the by-then-gazillion-warnings that will have been posted up to instruct them to do the right think on their servers/in their markup. Does IE even check the type attribute, actually, or is it just on the nonstandard “language” value?

In any case, the IE team is in no position to kick up a fuss about breaking the web. IE broke it in the first place, and those of us who get paid to build sites on a daily basis have been picking up the pieces ever since. You know how most standards-compliant accessible web development shops work? They build on KHTML or Gecko, and then once it’s done, they go back and patch it all up for IE7, IE6 and IE 5.5 (in that order) with conditional comments and the like. There’s a whole separate build cycle *just to make sites work in various versions of IE*. Do you guys understand the significance of that, or the cost to the industry? Sure, IE 7 is less trouble than IE 6, and IE 6 is less trouble than IE 5.5, but compared to everything else out there they’re all still a complete mess.

Seriously, right now, none of us care about ES4. It’s a hypothetical for at least the next five years anyway (because of backwards-compatibility constraints), and the solution to forward compatibility issues in the browser is trivial when you’ve ignored the standards indicators for so long. What we DO care about is what you people plan to do next in terms of mopping up this spilt milk—whether it’s IE 7.1, IE 8, or “IE Next Generation”: engage, inform, and get web developers on side for once.

IE didn’t break the web. IE lead the way for the better part of a decade.

I’m not all that concerned that IE doesn’t fully support CSS2, nor am I concerned that IE doesn’t support CSS3 at all.

What does concern me is that CSS is the only standard we have for the presentation of (X)HTML, and I think it is severely broken. Why does it not harness dynamicity of DOM objects for layout capabilities? Something as simple as making columns with relative and bound sizing is an effort and a half compared to what we did before CSS with tables!

Anyhow, my personal feeling about JavaScript is that I would rather see it buried and die than be re-invigorated. I hate developing with JavaScript, and not because of IE specific bugs. Sure, the standard might be alright and the language might be well written, but I don’t think it’s as suited to the web now as it was many years ago.

I’m very much in support of breaking away from ECMAScript and formulating a new spec that’s vastly more suited for web programming and AJAX-type applications. Where my opinions lie, however, is that said spec should be implementable as an API with bindings to multiple lanaguges, much like .net.

@Keith I don’t know what kind of work you do, but the great majority of web developers most certainly do care. The fact that CSS 3 has been moving so slow, is the reason you don’t have better support for things like columns. All browser manufacturers except for MS have implemented parts of CSS 3.

Previous versions of javascript were tailored for what was envisioned that they would be used for. At this point, like or not, that includes rich internet applications. As Actionscript and PHP developers found out, such a switch in focus requires major changes in the core language. Both development communities have lived through that transition just fine thank you very much. We don’t need another language or a bloated, confusing multilanguage runtime.

ES4 is more suited to AJAX. I suggest you read the spec. The typing system and the fact that you no longer need to run JSON through eval, make it much more secure for starters. The OOP structure and the package namespace, in my opinion will cause open source javascript development of frameworks and other scripts to explode.

None of this, including somehow managing to stuff a server side language like python or ruby into a suitably secure sandbox environment will fix IE’s IMPLEMENTATION of the DOM and event models. That is a separate issue. As I said before, I don’t really buy the excuses on that, but the idea that it isn’t important, is simply not true.

The NAME and ID might all be the same for you on your elements, but OTHER elements can have a NAME attribute and be valid! (e.g. the meta tag, or anchors)

The other issue, is that the NAME attribute is required for form submission, but the ID uniquely identifies an element. If I have a set of checkboxes to indicate available features, the NAME of all of them might be "features" but the ID for each of them might be "feature_2314", "feature_8347", "feature_9348" etc.

Therefore, the first rule to be aware of, is that NAME != ID, and therein lies the rub with this bug, IE implemented it wrong, and now the rest of us have to suffer. Step one would be updating the documentation on MSDN to at least reflect this really awful bug.

Second, the label tag was never meant to "wrap" the input field, and as you’ve noted, doing so in IE will render unpredictable results.

The "for" attribute if specified will link the label with the input field (matching by ID), if you use this, it works perfectly in all browsers. Keep in mind, that due to another IE bug, if you want to set this attribute programatically, you’ll need to set it like this in IE.

if(!IEBrowser){

foo.setAttribute( ‘for’ ,’feature_3345′);

} else {

foo.setAttribute( ‘htmlFor’,’feature_3345′);

}

/*note you’ll need to define/determine an IEBrowser variable/value

*/

More importantly, remember that every month, new developers hit the streets, ready to take on the web… they see the spec, for .getElementById( id ); and it pretty much is self-descriptive… then they go off an code with it, only to find out half way through the project, that there are serious gotchas with this method, and yup, they ALL HAPPEN in IE!

The post topic was about supporting future levels of scripting specs.. those of us reading this with any knowledge of IE just want the embarrassing mistakes that are already shipping to be fixed/implemented.. and quite frankly, none of us think that this is too much to ask after 7 !@#$&ing! years of development.

I haven’t seen one on this blog yet, but a survey/poll would be very handy.

Put out a poll, with a simple set of answers that cover all your needs. Let them run, analyze the results, and take them into consideration for future releases.

Suggesting for your first poll.

Q.#1) The JavaScript implementation of document.getElementById( id ) in Internet Explorer deviates from the specification (add link to it). Based on this, please choose the statement that best matches your view as a developer:

a.) Does not affect me, I am diligently ensuring my code does not trigger this bug.

b.) I depend on the broken implementation in IE.

c.) I am aware of the bug, but have written/used wrapper code to workaround the bug, therefore it does not affect me.

d.) I have no idea if the bug affects me or not.

Q.#2) Based on your reply to question #1, which approach to fixing this would you prefer?

a.) Fix the method.

b.) Leave it broken.

c.) Fix the method, but allow developers a way to access the old version (for compatibility).

d.) Either a or c.

I would be voting for: 1c, and 2a or 2d.

Once all the votes are in, take a look and see if anyone is answering 1b, or 2b. I honestly can’t imaging any developers choosing these options, but maybe I’m mistaken.

Generally, I think I can understand your scepticism towards the rampant growth of in ES4, which I share (e.g. turning a prototype-based language into a class-based language with interfaces seems pretty strange to me).

But some also pointed out, that your company may just have come late to the party, when ES4 had been pretty settled.

There is another area, where something similar could be happening, namely WHATWG/"html5". I don’t know if I entirely like the fact that an html5 effort from the W3C had to come about, but just like ES4 it _will_ come. I hope that at that time Microsoft will not state that nobody has talked to them, that the standard is broken and that Microsoft is rather committed to "not breaking the web" as it presently exists.

This is not meant as an offence but I get the impression that MS as a company is not terribly interested in evolving technical specifications unless your own company dominates them (e.g. Silverlight, .NET, OOXML).

@ronald: No, no one would answer 1b or 2b. That’s exactly the point– the people who built the sites that rely on broken behavior aren’t going to bother answering a poll any more than they are going to bother writing correct HTML/Script code.

Why should IE make the user suffer for the web developer’s laziness? He doesn’t care, he probably got paid and left the building a looooooong time ago.

"Why should IE make the user suffer for the web developer’s laziness? He doesn’t care, he probably got paid and left the building a looooooong time ago."

The same could be said to maintain the status quo. Someone wrote something dependent on incorrect behavior from Internet Explorer, and they’re no longer employed at the organization they authored it at. It will take time (and therefore *probably* money) for a business to go in and fix the bad code.

I would like to see things get fixed too, and I am curious what priorities some of the incorrect behaviors and missing features will be/have been given for IE8. I really hope someone gives the IE team enough of an excuse to fix the button stretch problem (not enough text + width too wide = ugly pixelated buttons). I can understand them not spending time on the HR margin thing.

"If you like Firefox’s Live Bookmarks, you’ll probably like Dave Risney’s free addon."

It’s a huge step up from having no live bookmarks. It’s missing a "Reload Live Bookmark" command on the context menu for a feed, and there are some behavioral differences (e.g. I move the live bookmarks to the Links toolbar [which I need to find a way to remove the "Links" text from as it is stealing screen real estate], so they’re right there above/below the address bar – but they do not behave like true menus. If I open a feed, and mouse over another one, I expect that one to open like a menu would).

When will you all (safari, IE, Firefox, and all the other browser dev teams) sit in front of a round table and get the specs straighten out?

I like the fact that you guys belive "thoughtful evolution is the right way to go". But if your thoughtfulness doesn’t get distributed across everybody, we the actual web developers will have to suffer at the end. Look at Firefox, they released a bunch of new javascript features that only supports on itself. No, IE didn’t follow. Nope, Safari didn’t follow.

I’m not writing to bash MSFT, but I’d seriously like to know how withholding info about IE8 is in any way helping the web development community.

I have yet to hear anyone other than MSFT call IE7 something other than a disappointment. Not to mention the fact that after 5 years of supposed development MSFT has given us yet another browser that doesn’t adhere to any standard.

@Chris Wilson

It’s no surprise that you would lean toward an "entirely new language"; which would no doubt end up being proprietary, non-interoperable, closed, and buggy without any developer support.

With so few improvements between IE6 and 7 why should the development take you seriously.

"After 5 years of supposed development" indicates that you don’t read the news. Microsoft themselves indicated that they worked on IE7 for two years, after a hiatus when they were only working on Vista and patching IE6.

The fact that the team is not saying anything about IE8 does NOT mean that no development is taking place. You may well be right that it could be some time before we hear substantial information. However I can’t believe that the IE team is doing nothing or that the IE team has been disbanded only to be reformed later. Both those alternatives make no sense. Chris Wilson talked about the investment currently going on in layout in an interview at http://www.sitepoint.com/blogs/2007/10/01/wds07-bonus-feature-chris-wilson-microsoft which clearly implies that development on the future of IE is taking place.

I share your frustration with the lack of information and the apparent slow pace of progress. However your suggestion that absolutely no development is taking place makes little if any sense. To have a team doing nothing or break up the team to reform it later would be ridiculous after Microsoft admitted that the break after IE6 was a mistake.

Microsoft is suffering from the not-invented-here syndrome. I can understand they want to include a browser with the OS, but just cut your losses and use one of the open-source engines that are available *right now* and don’t need another year of development. There are two very good engines out there that are years ahead of trident. Both WebKit and Gecko work very well and are quite fast. I’m sure both groups would welcome additional developers.