The Web Standards Project » Microsoft TF Working together for standards Fri, 01 Mar 2013 18:30:30 +0000 en hourly 1 IE8 Has Arrived Fri, 20 Mar 2009 13:14:20 +0000 agustafson As you may have heard, yesterday marked the official release of Internet Explorer 8. This new version of the oft-reviled browser has a completely rewritten rendering engine that was built, from the ground up, with the CSS 2.1 spec in hand. Improvements in this version include
  • 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?

]]> 35
Microsoft rethinks IE8′s default behavior Mon, 03 Mar 2008 22:50:21 +0000 agustafson interoperability principles, but Microsoft has decided to change its course on IE8 and will opt-in to its new standards mode by default.]]> This afternoon, in an announcement posted on the IE Blog, Microsoft officially reversed its position on IE8′s default behavior with regard to its new standards mode. The browser will now automatically opt-in all websites to “super standards mode” unless explicitly told not to (using IE’s version targeting mechanism).

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?

]]> 45
WaSP Round Table: IE8′s Default Version Targeting Behavior Sun, 24 Feb 2008 17:45:35 +0000 agustafson On 16 February, Web Standards Project Members Faruk Ateş, Porter Glendinning, and I got together with Chris Wilson, Platform Architect for Internet Explorer to talk about IE8′s proposed default version targeting behavior of having to opt-in to the browser’s new standards mode.

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:

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.

]]> 22
Opting-in to standards support Tue, 22 Jan 2008 14:21:26 +0000 agustafson A List Apart, I was (finally) able to reveal Microsoft's new strategy for forward-compatibility, a strategy that was developed hand-in-hand with several of us here at WaSP.]]> When IE7 came out, sites broke. Folks throughout the web community posited many reasons why, but none mentioned the fact that all standards-enabled rendering engines are triggered by an assumption we affectionately call the “DOCTYPE switch.” I’ll truck out a dusty old cliché here: “when you assume, you make an ass out of you and me.”

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.

]]> 9
IE8 passes Acid2 test Wed, 19 Dec 2007 20:53:43 +0000 blawson Blimey. Cor luvvaduck and no mistake. Just after the announcement that Opera are complaining to the European Union about Internet Explorer’s dodgy standards support, Chris Wilson reports that an internal build of Internet Explorer 8 passes the Acid2 test.

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

]]> 50
Talking with Microsoft about Sun, 04 Feb 2007 20:49:43 +0000 agustafson You may recall that the DOM Scripting and Microsoft task forces, in collaboration with JS Ninjas, had been compiling a list of issues, needs, and wants for over the last few months (a list many of you contributed to as well, via your feedback). The list was to focus on what we wanted to see happen in terms of JavaScript support (as IE7 didn’t get much of an update in that area), but when it came down to it, there were other areas we really felt needed some love.

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, 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 The IE team wants to continue this conversation and to continue to elicit feedback from the web community as a whole as things progress.

]]> 21
You can improve Sat, 04 Nov 2006 17:49:32 +0000 agustafson The Microsoft Task Force, DOM Scripting Task Force, and the JS Ninjas have been approached to help give the IE team some direction for improvements needed in, focusing mainly on JavaScript and the DOM. Together, we’ve begun assembling a list of things we think need addressing (bugs & implementation issues, enhancements in language support, etc.). We’ve tried to keep it balanced, with some things for the seasoned JavaScript developer and some for the folks who are just starting out in the world of DOM Scripting, but we need your help to make sure we aren’t missing anything.

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.

]]> 75
Microsoft predicts swift adoption of IE7 Sat, 28 Oct 2006 15:49:02 +0000 agustafson As part of his keynote at The Ajax Experience in Boston earlier this week, Chris Wilson, Lead Platform Architect for the IE team (and a WaSP Microsoft Task Force member), revealed that Internet Explorer 7 was downloaded about 3 million times within the first four days of its release. He also offered that, according to Microsoft’s own numbers, 90% of the Windows web share is running [Windows] XP, which goes a long way toward relieving concerns that Microsoft’s plan to only offer IE7 to users of Windows XP and beyond will slow its adoption and never free us from the problematic world of IE6 support:

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.

]]> 26
IE7 JavaScript Improvements Thu, 21 Sep 2006 15:09:29 +0000 deanedwards The IEBlog recently reported some improvements in IE7’s JavaScript engine.

The IEBlog recently reported some improvements
in IE7’s JavaScript engine:

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

]]> 14
IE7: The List is In Wed, 23 Aug 2006 03:28:11 +0000 mollyeh comprehensive list of bug fixes, implementations and developer/designer resources for IE7 has been published by Markus Mielke of Microsoft (and also a member of the W3C CSS Working Group) on the IEBlog today.]]> The list, which includes 200 issues that have been addressed including such coveted features as alpha transparency support for PNGs; the :hover dynamic pseudo class available for all elements; and min/max width supports.

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.

]]> 19