Web Devout tidings

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.

I haven’t been posting much lately, since I’ve been focusing on actually getting things done, but I wanted to point out what I think is a very good decision from Microsoft that seems to show they’re really serious about standards.

Historically, CSS property vendor prefixes (-moz-, -o-, -khtml-, -ms-, …) have generally been used for properties that either aren’t part of a current CSS standard or are part of a current standard but only have experimental support by the browser. But most browsers have made exceptions to these rules depending on how common the non-prefixed versions are on the Web.

Microsoft has announced that they are taking a clear-cut approach to this topic and will always follow these convention rules. In Internet Explorer 8, webpages invoking the best standards mode (default) will be required to add an -ms- prefix to vendor-specific properties like filter, scrollbar-base-color, and zoom, as well as non-finalized CSS 3 features like background-position-x, overflow-x, and word-wrap.

Microsoft claims that every CSS 2.1 property will be considered supported, so no CSS 2.1 property will require a vendor prefix.

Now, here’s why I think this decision is so significant: Asking a browser to always follow the vendor prefix conventions is a picky request. An unreasonable request, some might say. I’ve argued about this subject a number of times in the past, and I’m usually dismissed as a silly idealist for wanting browsers to deliberately break support for current websites just to follow a convention with fairly hard-to-see benefits.

Most people don’t know or care that breaking the convention introduces possible complications for the development of future standards. They just want to see the “Passed Validation!” message in CSS 3 mode. They’re more concerned with the short term issues of getting all the lights to turn green than the long term issues of the growth and stability of sound web standards.

Microsoft’s decision makes some short-term sacrifices for the interest of the long term health of the Web, and it’s on an issue that even many standards advocates would consider picky. Well, I for one am thrilled to see Microsoft getting “picky” about the quality of their standards support.

Update 2008-09-09: I should clarify that the non-prefixed properties that were supported in IE 7 will continue to be supported in IE 8, with or without the prefix. But Microsoft considers the non-prefixed versions deprecated, and they may be removed in a future version.

The exception is the filter property, which will not work in IE 8 standards mode without the prefix. This is because the original filter syntax didn’t comply with CSS’s grammar rules and will thus be ignored in IE 8’s improved CSS parser. If you have to continue using the filter property, you need to include the prefix and put quotes around the property value. For compatibility with older versions of IE, you’ll need to write the filter both ways.