• the death of hasLayout
• object fallbacks
• stylable legend elements
• generated content (including support for dynamic attribute insertion via attr())
• CSS counters
• support for the quotes property
• outline control
• data URIs
• full access to the style attribute via the DOM
• mutable DOM prototypes
• and much more

This browser is a giant leap forward for standards support at Microsoft, but reviews so far seem mixed. What do you think?

So what does this mean? Well, a few things:

1. Standards-based developers will not have to add an additional header to their server or another meta element to their markup to realize the benefits of IE8′s new rendering and scripting engines.
2. Any non-standards aware developers will need to be educated to either a) implement version targeting, or b) get their site compliant.
3. Anyone using JavaScript that engages in browser sniffing will need to replace that for feature detection (and check their third-party code too) as many assumptions about IE’s scripting engine could be proven false in this release.

This was a very complex issue and I fully understood and had come to accept Microsoft’s earlier decision to break with convention and not automatically opt sites in to the new engine, but I have to say I’m glad they’ve reversed that decision. In the end, this does put more pressure on them to get the word out about how version targeting can prevent a recurrence of the issues that came about when IE7 released, but, personally, I feel their product (and the web at large) is better for it.

What do you think?

As you may recall, the version targeting opt-in requires developers to use the new X-UA-Compatible HTTP header (or the meta equivalent) in order to take advantage of the standards-based layout and scripting improvements in the IE8. Under the current setup, any page/server not opting-in to would continue to render and behave as though it were being viewed in IE7, even if the site was being viewed on IE8, IE9, or IE1000. This doesn’t sit well with many standards-aware developers who think that the IE team got it backwards; many of them believe that you should have to opt-in to keep your site from being interpreted by newer layout and scripting engines. (Folks interested in hearing both sides of that argument should check out the latest issue of A List Apart, where Jeremy Keith and Jeffrey Zeldman square off on the topic.)

In our “round table” discussion, we talked about several proposals from the community that could help bring IE8′s standards mode to the masses, including:

• encouraging Microsoft to ship a patch to IIS that automatically targets sites run on that server to IE7 (in hopes of avoiding the potentially catastrophic impact IE8 may have on intranets and the like);
• shipping the IE8 beta with standards mode on by default just to see how many sites break; and
• making IE8 a standalone browser, capable of being run side-by-side with IE7 to allow users the flexibility of using one broswer for some sites and the other for other sites.

If you are interested in listening to or reading a transcript of the discussion, you can do so by following one of these links:

• WaSP Round Table: IE8′s Default Version Targeting Behavior [mp3]
• WaSP Round Table: IE8′s Default Version Targeting Behavior [transcript]

I’d like to give special thanks to fellow WaSPs Glenda Sims and Steph Troeth for organizing, producing, and transcribing this Round Table.

This buzz has been translated into Polish.

So what does that have to do with the DOCTYPE switch? Well, the DOCTYPE switch assumes that if you are using a valid DOCTYPE for a “modern” language (e.g. HTML 4), you know what you’re doing and want the browser to render in standards mode.

That assumption could have worked out all right, had it not been for authoring tool makers who—with the best intentions and under pressure from us (the web standards community and WaSP, in particular)—decided to include valid DOCTYPEs in new documents by default, thereby crippling the DOCTYPE switch because it wasn’t an explicit opt-in. Now add to that the fact that IE6 had the lion’s share of the browser market for so long—thereby becoming the primary browser in which many developers tested their work—and you have a recipe for disaster: developers assumed (there’s that word again) the layout they were getting in IE6 was accurate, not realizing they had been opted-in to accept rendering engine upgrades as the browser evolved (all of which was reinforced by the 5 years of stasis in terms of IE6′s rendering).

So along comes IE7 with it’s tuned-up rendering engine and, well, it caused sites to broke.

Not wanting to see that happen again, Microsoft approached us (WaSP) to help them find a better way of enabling standards support through an explicit opt-in. You can read more about the thought process we went through in my article on A List Apart. The issue also features a commentary piece by WaSP alum Eric Meyer (who was not involved in the development of the solution, but was asked for feedback on our work) that takes you on the mental journey he took in reaction to our recommendation. The series for ALA—on what we are calling “browser version targeting”—will wrap in two weeks with a piece by Peter Paul Koch—who, like me, was involved in the development of this technique—that will cover application of the browser targeting mechanism in IE8 and beyond.

This buzz has been translated into Polish.

This doesn’t necessarily mean that IE8 has fixed all its float oddities, or its hasLayout hilarities. But what it does mean is that there is another browser war, and Microsoft did decide to come.

Added 20 December 2007: Markus Mielke of the Internet Explorer team confirms “HasLayout will be history with IE8“. Exciting times…

(This post translated into Polish.)

The list

Last week, our groups voted for what we each saw as priorities and those votes were tallied to create a final list for me to present in Redmond. Though there is obviously a great deal more we want to see in IE.next, we felt several things were critical and wanted to focus on those as a starting point.

Tied for first place, in order of priority, were some sort of fast, arbitrary node-matching API and better error reporting. In the realm of DOM Scripting, node-matching is key (just look at the number of scripts out there performing node matching based on CSS selectors, etc.), so being able to tap into a native XPath implementation (which we generally favored over the Selectors API) would greatly improve the speed of script execution. As for the error reporting, perhaps Justin Palmer (of JS Ninjas) said it best:

We could possibly find ways to fix all the other problems if we could tell what the hell was breaking and why. Without better error reporting, the remaining stuff on that list is just giving us a bigger gun to shoot ourselves in the foot with.

Next up in our list was a desire for mutable DOM prototypes. This would address the issues that arise from IE’s implementation of DOM objects in JavaScript, where elements of the core DOM are not derived from the standard Object prototype. While not technically a standards-support issue, this request does not conflict with standards and it does provide JavaScript developers with the ability to address some of the issues the IE team may not be able to address themselves in the next release. As Andrew Dupont (another Ninja) remarked, I think it’s reasonable to ask that a DOM implementation in JavaScript behave like it’s part of JavaScript.

Next up was a biggie: bring IE’s event system in line with the W3C event model. This has been an issue for a lot of developers and the code to equalize the two event systems makes up a significant chunk of all of the major JS libraries. Getting IE to implement the W3C event system would be a real boon for standards support and would drop the size of many libraries considerably.

Finally, the last of our top 5 was not a JS issue, but rather a CSS one: implement generated content. I don’t know that I really need to get into the reasons why this would be really nice to have.

Two “honorable mentions” were included in the list as well: fixing the issues with getAttribute() and setAttribute() and starting to implement some of the features of JS 1.7 (such as block-scope variables using let, etc.).

Not willing to let the IE team off that easy, the document presented also highlighted several other issues which really need addressing including (among others)

• fixing CSS bugs (including collapsing adjoining margins and z-index);
• various form control fixes (including implementations of the button element, labels, and the disabled attribute);
• correcting its support for object;
• adding support for the q element (which should be a breeze once generated content is enabled); and
• fixing attribute issues (such as alt being used for a tooltip, cite not being supported on q and blockquote, and summary not being supported on tables).

The meeting

In Redmond, I met with Pete LePage, a Product Manager at Microsoft Web Platform and Tools, and several other key members on the IE team. We discussed the list and its implications in great detail for nearly two hours. While I am not at liberty to discuss all of the details of the meeting, I can say for certain that the group I met with was keenly aware of the issues we brought up and are eager to address them. One team member even said that he could have easily guessed our top 5.

The one concern they have—especially with regard to the event model and getAttribute()/setAttribute()—is that any adjustments they make to bring IE in line with the standards not “break the web” for the large number of sites using the proprietary IE event model, etc. We discussed this particular topic at length as it is a valid concern and I’m happy to say that I think we’re close to a solution on that front.

I came away from this meeting with a real sense of hope about where IE is going and am really encouraged by their willingness to engage the standards community (and web developers as a whole) in dialog like this. We did not resolve every issue in our two-hour talk, but I was assured that this was only the first of many steps toward improving IE.next. The IE team wants to continue this conversation and to continue to elicit feedback from the web community as a whole as things progress.

In the interest of time and keeping the process streamlined and organized, we’ve opted to make the wiki invitation-only, but we do need your input. Please have a look at what we’ve put together so far and leave your thoughts/ideas/recommendations in the comments below. We don’t know how soon we’ll need to get this list over to the IE team, so please don’t wait to long.

We will work to incorporate any relevant ideas into the final list, prioritize it, and pass it along to the IE team. Once the list is out the door, we will need to develop test cases for each item on it (some of which we’ve already begun), so if you are interested, please let us know that as well.

Note: We’re not guaranteed to get everything we ask for, but they are listening.

I think that you’ll actually see, and granted this is a little early since [it's] only been out for five days or something, … the curve on this [and it] will quickly be clear how soon we’ll get to ditch IE6 … I can’t really predict that, but I think you’ll find it’s going to be quicker than what most people expect today.

Chris also mentioned that the adoption thus-far has come without Microsoft pushing the browser update via its Windows Update service and I don’t think anyone is ruling out the possibility that Microsoft may choose to go that route, eventually.

If Chris is right (and I hope he is), this is very good news for standards-based developers. While it is true that IE7 is far from perfect, it is a much needed step on the way to a world without CSS hacks and workarounds and one with more standardized DOM support. Having also had a few off-the-record conversations with folks from the IE team attending the event, I can honestly say I feel confident that we (the standards community) have Microsoft’s ear and that they are very interested in knowing what they can do to make our lives easier now and in what they are casually referring to as “IE.Next.”

If you’re interested in seeing a snippet of video from the speech, captured by Molly, jump on over to her post on the topic.

We have heard a lot of requests to improve our Jscript engine, especially now that AJAX
sites are becoming more prevalent on the web. I want you all to know that we have been
listening and have recently made some great fixes to our engine to improve the garbage
collection routine and to reduce unbounded memory growth.

This was confirmed by tests performed by the qooxdoo developers:

In fact many demos of qooxdoo
run much faster now in IE7 compared to IE6. And they are even faster than in Firefox 1.5 in many cases.
This is a huge jump in performance. Microsoft did not tell about their exact modifications, of course.
Anyway, they have fixed the major problem of large JavaScript-based web applications. This problem,
despite having a catchy name, was mentioned many times before like
here,
here and
there:
If you have many objects created, which are simply accessible in the current scope, all
methods and features of JavaScript slow down dramatically.

It would be great if these bugs were fixed so I emailed
Chris Wilson for comfirmation. He replied:

Yes, it is true we’ve done some dramatic improvements to JavaScript
performance. I wouldn’t say we’ve fixed everything, but we’ve addressed
a bunch of memory leak problems and most significantly, taken a
different strategy for the Jscript garbage collector. This last one
makes a huge difference in many current JavaScript-heavy pages.

Good news indeed.

More details and views on what was fixed, what wasn’t and how to prepare your sites for IE7 are available via Markus’ post.

The work Microsoft has done in IE7 is impressive, and I am confident that it is a significant step forward in the improvement across all browsers.