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:

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:

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.

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m around at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies:

Comments

Comments are closed.

1 Posted by Moondog on 1 September 2008 | Permalink

I am happy you pointed out there are differences between the rendering modes of IE8 and "the real thing(s)".If the rendering modes IE is supposed to clone are not 100% accurate they are not useful as a test bed; coupled with the fact that you can't install two or more IE versions in parallel this will lead developers into thinking they have a working page for legacy browsers, when in reality it is not.
Case in point: I have a page HTML 4.01 Doctype, standards mode, which uses explorercanvas: the page works fine in ie7, it won't work in ie8 even if the x-ua-compatible header is set to IE=7 (or IE=EmulateIE7), unless I switch to quirksmode...not a nice option considering the divs will move all over the place.
How am I supposed to fix the page?
Any IE8 version will display a broken page, even with the correct x-ua-compatible header which is there exactly to prevent these problems:
if the rendering modes are not exactly the same our brand new pages with "IE=8" will be broken again when ie9 comes out. I feel like I'll have more work to do, not less, with more versions to target the pages for. Your take?

2 Posted by Gavin on 1 September 2008 | Permalink

While its great that Microsoft are cleaning up its act, it'll be several years before we can start ignoring IE6 for public websites.

Despite IE7 being released 2 years ago, I still see 1/4 of my web traffic from IE6.

I do applaud the effort though.

3 Posted by graffic on 1 September 2008 | Permalink

@Gavin: just ignore IE6 and these users will move to another browser. (of course complaining and blah blah blah, but at least they'll move from IE6).

An effort to improve is always good. But if it's time to switch to "Standards", if it's time to switch to a "Better web experience", or better "CSS, JS, XHTML..." support. Then, it's better to do the change and jump away from Microsoft.

BTW: really good round-up :)

4 Posted by Party Ideas on 1 September 2008 | Permalink

@graffic - this argument comes round and round again, but do you really think if an IE6 user finds your website all weird looking he'll a) give up and go to a competitor's that does work or b) become versed in the standards debate, realise his browser is not standards-compliant and upgrade to something else? Course b would be pretty suicidal for anyone running a commercial operation.

Regarding IE8: I think the 'broken page' icon that appears _regardless_ of what's in your page is the IE8 team's worst idea. What are regular user's going to think? At the moment the only way to get rid of it is by using a meta or http header.

5 Posted by Weston Ruter on 1 September 2008 | Permalink

So IE8 Betas 1 and 2 behave the same way as IE6 when it comes to unrecognized elements. This is a huge problem for forward-compatibility looking ahead to HTML5. I use new HTML5 elements in several projects and they work great in IE7 if a special shim (http://ejohn.org/blog/html5-shiv/) is applied. In IE6 and now IE8 as well, if a fragment with unrecognized element such as test is encountered, it is erroneously parsed in the DOM tree as three sibling nodes with the following nodeNames:

1. NAV
2. #text
3. /NAV

Whereas in IE7 and IE8 in compatibility mode parse then as follows:

1. NAV
--a. #text

Which is the same behavior as Firefox, Safari, and Opera.

Is IE8 going to be so rigidly standards-enforcing that it is going to be completely blind to the future?

(I posted the same comment on the IE blog: http://blogs.msdn.com/ie/archive/2008/08/27/internet-explorer-8-beta-2-now-available.aspx#8903666 )

6 Posted by Richard Fink on 3 September 2008 | Permalink

window.onresize doesn't work only in IE8 Standards Mode.
The onmove event is likewise broken in that mode.
In emulateIE7 and Quirks Modes, it works fine. And, strangely, onresize WILL work in IE8 Standards Mode when attached to an iframe.
No doubt it will be fixed, and I'm getting the feeling some of the omissions in IE8 Standards mode might be intentional - a way of removing variable conditions so they can focus in on specific problems as the bug reports come in.
Thanks for the report.

7 Posted by Tino Zijdel on 4 September 2008 | Permalink

The <meta> switch is completely illogical. Imo the EmulateIEx switches are totally unnecessary and confusing; the 'normal' X-UA-Compatible=IEx should have the behaviour that the EmulateIEx switches now have. It makes no sense to have a switch that takes precedence over doctype switching since no other browser has that. MS could have easily corrected that but instead opted to introduce yet another switch (the EmulateIEx one which has a more sane behaviour).
I really wonder sometimes if they know what they are doing over there in Redmond...

8 Posted by seo on 4 September 2008 | Permalink

Thanks for sharing the insights

9 Posted by Condor on 23 September 2008 | Permalink

The CSS compatibility table for opacity and text-overflow in IE8b2 should be corrected:

Microsoft has prefixed all non-CSS-2.1 properties with -ms- and a -ms-filter expression needs to be quoted.

Source: http://blogs.msdn.com/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx