I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

IE8b2 round-up

Right. Now that IE8b2 has been out for five entire days, it’s time for a round-up. Exactly what has the progress been? Any regressions? And what about the <meta> switch. How exactly does it work?

All in all I’m quite happy with the progress being made. In addition to a few stunning JavaScript additions, there’s gradual progress across the spectrum. CSS and DOM support has become better; not stunningly so, but still quite important.

First of all the horse’s mouth. Here’s Microsoft’s own round-up of additions and improvements.

My research largely concurs. I’ve updated the CSS, DOM Core, DOM HTML, DOM CSS OM View and Events Tables, and in general the improvements are small but significant.

Attributes

For instance, ever since I started creating compatibility tables back in 2000, IE has had grave problems with most methods and properties that have to do with DOM attributes. Its attributes[] list contained not the attributes that were actually defined on an element, but all attributes that could possibly be defined on that element. At the heyday, the array contained 84 (!) entries.

No more. attributes[] has been improved and now contains only the attributes defined in the HTML; just as it does in all other browsers. There are many similar small but important updates in other aspects of attribute handling.

Also, properties and attributes used to be equivalent, with link.href meaning the same as link.getAttribute('href'). This has been discontinued; HTML attributes and JavaScript properties are now different things, and setting the one doesn’t necessarily influence the other.

CSS

Similarly, CSS support has become better. Most of that improved support was already visible in IE8b1, but several bugs (most notably the impossibility of using images for anything else than background-image) have been fixed.

The MSIE team is serious about its stated goal of full CSS 2.1 support: even relatively unimportant declarations such as visibility: collapse on table columns and element:before {content: none} (which should remove the :before pseudo-element) are now supported.

JavaScript

But the real progress is in JavaScript:

• querySelectorAll() is supported.
• Getters and setters are supported, but only on DOM objects.
• Mutable DOM prototypes are supported (i.e. you can now do Element.prototype.getElementsByTagNames = function () {etc} )

Mutable DOM prototypes

That last point is especially important. However, as soon as you try to actually work with prototypes, you’ll quickly find that support is not perfect yet.

Most importantly, the Node interface is entirely missing. More in general, the IE model is a shallow one: it contains the Element interface and directly below it the HTMLXXXElement interfaces. Besides, comments are HTMLCommentElement interfaces and inherit from Element.

All this is only a partial implementation of the spec; large swaths of interfaces are missing, and making the comment interface inherit from Element is just plain wrong. Why did Microsoft release this sub-optimal implementation? An MSIE developer explains:

The interface objects (constructors) and interface prototype objects defined for Beta2 are based on the structure and function of IE's internal object model. Early on, we had to decide if we wanted to implement a "fake" layer for the constructor/prototype objects that looked identical to the W3C model, or to expose what we had, warts and all. While the warts weren't particularly attractive, they do help to bring clarity to the way that the DOM is represented internally and avoid having a whole series of internal mapping bugs between what is actual and what is veneer.

The choice was between reliable partial support or fake full support with bugs, and the IE team chose the first. Fine by me.

BTW: a post on the IE Blog about this subject is being prepared and will hopefully run in the next few weeks or so.

Bugs

Since IE8b2 is a beta, it contains a few bugs. The most curious one is a bug I found in the insertBefore, setAttribute (style only) and applyElement tests. All these tests work fine, but the result only becomes visible when you click on the element that you changed and/or mouse out of the list of test links. Obviously a bug; will obviously be fixed.

Similarly, the resize event has stopped working, and the mousewheel event backfires: the mouse wheel doesn’t work when a handler for this event is defined.

Finally, there’s something wrong in positioning: when you apply position: absolute or fixed, the green layer in my test page mysteriously disappears.

The <meta> switch

Finally, what about the <meta> switch? Exactly how does it work, and what should we do to pick the rendering mode we want?

I created a few tests to get to the bottom of the switch once and for all. The tests feature a few CSS declarations whose support changed from IE5.5 to IE6, or from IE6 to IE7, or from IE7 to IE8.

I created one page for each combination of a <meta> switch and a doctype and used the support or non-support for the various CSS declarations to determine in which IE rendering mode the page is shown.

The conclusions were:

• If there’s no <meta> switch the doctype switch is obeyed. Quirks Mode means IE5.5 mode, while Strict Mode means "best available rendering mode". Right now that’s IE8, but once IE9 comes around any Strict Mode page will be rendered in IE9 mode.
• However, the <meta> switch trumps any doctype. When one is present the page is always rendered in the IE mode defined by the switch.
• The two Emulate values go back to the doctype switch for more information. A Quirks Mode doctype means IE5.5 rendering mode; a Strict Mode doctype means either IE7 or IE8 (EmulateIE7 and EmulateIE8, respectively).
• The Emulation button in the toolbar only appears when you’re viewing a page without a <meta> switch and with a Strict Mode doctype. In that case, clicking the button starts up IE7 rendering mode.
  In all other cases the button is not available.

By the way, the rendering modes in IE8 are not exactly the same as the ones in previous browsers. For instance, I wanted to make display: list-item one of my test declarations, since it was added in IE6 and is not supposed to work in IE5.5 . However, it turned out that IE5.5 mode also supports this particular declaration. Therefore I removed this test.

Conclusion

All in all IE8b2 is a huge step forwards (more so than b1, I’d say), and although we’re not there yet, the IE team has given a clear indication where it’s headed and that it’s serious about improving standards compliance.

Comments

Comments are closed.