Web Devout tidings

Okay, it wasn’t quite that dramatic, but the graphics card on my Windows laptop putzed out today (just as Michael Scott was sneaking back into the building), and I won’t be able to get it fixed/replaced until at least next week. That means I’m not going to have any IE 8 standards support updates this weekend. I still have my Linux desktop computer, so I’ll use this time to work on the information for other browsers instead.

I need to start this post with a giant asterisk: I’ve barely done any regression testing yet. With the exception of one regression a commenter found, my initial results assume that IE 8 doesn’t have any standards support bugs that weren’t in IE 7. This is a big assumption, since IE’s CSS engine was largely (perhaps entirely) rewritten for IE 8. I expect IE 8 to have a number of new bugs which aren’t yet documented in my tables, and those bugs will be discovered and documented over time.

Alright, now that that’s out of the way, let’s get to the current results. IE 8 has fixed almost every single CSS 2.1 compliance bug from IE 7. I’m currently counting a total of 17 “Incomplete” values (7 of which are due to the single regression mentioned above), with everything else being a “Y”.

This is a huge deal. While I can’t yet comment on the CSS 3, HTML, or DOM support, IE 8’s CSS 2.1 support is now right up with the competition. We still have to see how it holds up after more regressions are found, but it is currently ranking as the #1 most CSS 2.1-compliant web browser I’ve tested. This is truly excellent work from the IE team.

In the next version of IE, I would like to see some focus on getting rid of a number of “temporary glitches” I’ve noticed. They appear to be similar to the reflow bugs that plagued Firefox 2, in that merely hovering your mouse over the element or interacting with stuff around the element will often correct the glitch. An example is the tabs in the Webpage test system. I don’t think there’s any neat little box in my tables where I can document these issues; they seem more related to IE just losing track of stuff during painting.

I’m going to do the CSS 3 testing next.

I just wanted to give a little update about where I am on the standards support testing for IE 8. I just got the final version installed this morning, and I’m committed to getting the CSS results out by the end of the weekend.

I’m currently about a third of the way through the CSS section, and so far IE 8 is looking very good. It isn’t all “Y”s, but it’s been pretty close so far. I’m not making any final judgments until I’m done testing, but I suspect that IE 8 is now what I’d consider a “modern” browser in CSS support.

I also made a slight change to the Webpage test page to help with testing: When visiting it in IE 8, there is now a checkbox that says “IE 7 mode”. When you check it and hit the “Display” button, the output will be the IE 7 rendering. This is accomplished via the X-UA-Compatible HTTP header.

Stay tuned.

I can’t believe these debates are still happening. A number of blogs have been spreading around this rant about why CSS is bad at layout, and the old debate of CSS vs. table layouts has been reignited.

The one big thing people seem to be forgetting is that CSS can do table layouts without table elements! So the main benefits of table layouts are possible in pure CSS layouts using divs or other elements. The main problem with CSS table layouts is that Internet Explorer 7 and below didn’t support those parts of the CSS specification (while all other browsers have supported them for a long time now). But that’s a shortcoming of Internet Explorer, not CSS, and Internet Explorer 8 will have support for CSS table layouts.

I’m not saying that CSS table layouts are perfect. There are two other significant shortcomings of CSS table layouts:

First, CSS 2.1 doesn’t provide for a way to specify that a cell should span multiple rows or columns (as HTML’s rowspan and colspan attributes allow). In most cases, this limitation can be worked around by mixing the CSS table layouts with other CSS layout methods.

Second, CSS table layouts usually require lots of nested divs. It doesn’t require any more elements than HTML table layouts require, but it’s still quite bulky compared to other CSS layouts, and it demonstrates how dependent CSS still is on the underlying markup. CSS 3’s pseudo-element model will help mitigate this issue somewhat.

However, if the argument is that CSS doesn’t support the kinds of flexible grid layouts that HTML tables support, that argument is simply incorrect. Sure, CSS isn’t as markup-agnostic as it could or probably should be, but the use of HTML tables for layout is not a better solution.

I know I’ve gotten behind on browser testing, but I’ll definitely be reserving some time in the next couple of weeks to run the newly released IE 8 release candidate through the gauntlet, as well as bringing the Firefox and Opera information up to date. Safari might even get some love, if I can find enough time to get it all done.