Web Devout tidings

Since this site’s standards support resource was referenced in an article linked to on Slashdot, there has been some renewed discussion critical of Microsoft’s efforts in browser development. I have seen some blogs such as Web 2.0 Explorer and Download Squad complain that Internet Explorer 7 won’t be fully CSS 2.1 compliant.

In a somewhat rare move, I must come to Microsoft’s defense on this one. As far as I know, Internet Explorer 7 isn’t adding any nonstandard features to CSS and the developers have put forth a lot of work to fix as many of the most common CSS bugs as time allowed them. After a recent update, my tables currently show that Internet Explorer 7 has 55% support for CSS 2.1, up from 51% in IE6. That’s a 4% improvement. Although that doesn’t sound like much, it should be noted that it’s about the same total difference that the latest versions of Firefox and Opera have improved over their predecessors (Firefox 1.5 showed a 5% increase and Opera 9 showed a 3% increase).

The CSS standard is very large and complex, and I’m not sure if Microsoft is structured in such a way that they can put too many more people on the Internet Explorer core development team without it becoming too disorganized. All things aside, a 4% increase isn’t too bad for a year’s worth of work considering the other more user-focused improvements. It certainly doesn’t put Internet Explorer anywhere near where we web developers would like it to be, but that simply isn’t a realistic possibility in this short amount of time. In fact, considering that they’re adding improvements at about the same speed as the other browsers, it’s doubtful that Microsoft (or any company in their position) can catch up to the competition in the foreseeable future. That’s a reality we have to face, and it isn’t really the fault of Microsoft’s current efforts, but its past efforts (or lack thereof).

I think the Internet Explorer developers are starting to get it. They’ve been opening up lately and have expressed growing care for standards. I don’t see how Trident can become a decent layout engine without a ground-up rewrite as every other major layout engine had in the CSS era, but the developers are doing what they can. In IE7, Microsoft showed a willingness to break backwards compatibility in the interest of standards, and I think that was a very important precedent to set. I don’t know if they’re likely to rewrite the engine from scratch, but they are no longer giving the finger to web standards and I don’t believe the developers deserve the disrespect many have given them for the work they are doing right now. What I believe Microsoft deserves disrespect for is the long wait they gave us and all of the proprietary junk beforehand.

Yes, Internet Explorer’s standards support is still abysmal compared to Firefox and Opera, and at this rate it looks to be so for many more versions to come. But I don’t see any reason to chastise Microsoft for what they’re currently doing. Instead, ask why they waited so long if they knew they were unable to catch up afterwards, and encourage the public to select their web browsers based on the true quality of the browsers and not simply based on the browsers’ market inertia. As alternative browsers gain a powerful market share, web developers can begin sneaking newer standards into their websites and drive the public to using only modern web browsers. If Internet Explorer can’t handle what all of the other competitors can, then it’s a simple survival of the fittest situation and the worst browser is left in the mud. If Microsoft can pull a rabbit out of their hat and make Internet Explorer a true competitor, then there should be no complaints. Internet Explorer 7 has a decent amount of improvements, and we’ll see where the developers take it from there.

But I’m still hoping for a full engine rewrite.

I finally sat down and finished the standards support information for Opera 9.

Opera 9 shows some major improvements in key areas. The CSS information was discussed earlier, and here are some of the HTML and DOM support highlights:

• Various minor HTML support fixes.
• Support for Document.adoptNode().
• Improvements to XML namespace support in DOM Core.
• Support for Node.textContent.
• Improvements to DocumentType (document.doctype) and Notation and Entity interfaces.
• Huge improvements in DOM Level 2 Style, surpassing Firefox 1.5’s support in some areas. Includes near complete implementation of DOM Level 2 StyleSheets and most of DOM Level 2 CSS (excluding the CSSValue interface, a number of other interfaces related to CSS property values, DocumentCSS, and DOMImplementationCSS).

According to the tables, HTML/XHTML support has increased by under 1% and DOM support has increased by 6%. The tables now put Opera 9’s overall DOM support above Firefox 1.5’s: 84% compared to 79%, with Internet Explorer 7 at 51%.

Late March 2006, Microsoft anounced the Internet Explorer feedback system, aimed to provide users with a way to submit and publicly view bugs and feedback suggestions much like the user end of Bugzilla. Unlike Bugzilla, this would not be a place for the developers to discuss and chart their progress, but it attempted to provide end users with similar functionality.

Introducing this kind of system was a very good move, since there had long been a feeling of distance between the Internet Explorer developers and the users. This kind of system would provide a centralized location for users to discuss issues, rate their importance, and provide workarounds. I have personally submitted 11 reports using this system and have provided information for several other reports. This system had the potential for being an incredibly useful resource for web developers searching for information on Internet Explorer issues, which for many amounts to a majority of the web development process. Perhaps most importantly, this system would give us some insight into whether or when the issues would be addressed by the IE developers.

And that is precisely where the system has failed. Report after report has been closed with “Won’t Fix” or “By Design”, implying the issue will be indefinitely ignored, often without any further explanation. And these aren’t simply minor preference issues, but things that frequently cause real problems in the design world.

Here are some of the issues that Microsoft has marked as “Won’t Fix” or “By Design”:

• CSS borders aren’t supported on table-column (col) elements – “Won’t Fix”
• CSS “inherit” keyword isn’t supported for anything but the “direction” property – “Won’t Fix”
• CSS “input:active” isn’t supported – “Won’t Fix”
• IE doesn’t pass Acid2 – “By Design”
• No support for implicit HTML labels (<label>Name: <input></label>) – “By Design”
• Object element unusable for images (always displays with scrollbars) – “By Design”
• PNG images generated by Photoshop and some other graphics utilities are displayed off-color (PNG gamma correction isn’t correctly supported) – “Won’t Fix”

Before you panic, this doesn’t necessarily mean that they plan to never fix the issues.

For instance, the feedback system administration has adopted the practice of marking a report as “Closed; By Design” if it was filed as a bug and the administration thinks of it more as a feature suggestion. Ultimately, this depends on whether or not the issue is what the developers originally intended to happen or otherwise feel is expected behavior considering their particular implementation, regardless of whether or not it’s part of the standard or even documented by Microsoft. For us web developers, there often seems to be no difference at all between what they want filed as a bug report and what they want filed as a feature suggestion. In these cases, rather than simply changing the submission type to their preference, the administration closes the report and presumably expects someone to resubmit the report as the other type. This has caused considerable frustration among the users of the feedback system.

Furthermore, they seem to waver back and forth on what the terms mean. Sometimes, they resolve a report as “Won’t fix” when they just can’t get to it by the next version, while the official definition is “We know that we will not be addressing the reported issue, usually because it risks breaking the code in other, more serious ways or because the effort to fix the issue is not justified for the improvement.” At other times, they simply leave it as “Active”, despite the exact same explanation in the comments. Meanwhile, there is another resolution status called “Postponed” which is designed for this kind of decision, yet I haven’t seen it used.

Presumably due to lack of manpower for testing and moderation, Microsoft has announced that within the next couple of weeks they plan to close every report that has been in the database for over a month, asking users to manually reopen all reports that still apply in Beta 3, which will likely account for nearly all of the reports currently open. It seems the system as it is currently designed is unable to scale to reasonable levels and they are letting it collapse in on itself, then turning around and asking us to rebuild it on the same shaky foundation. They are making it incredibly difficult to use the system for its intended purpose, while seemingly not taking the feedback we give them seriously. This creates a very frustrating situation for users who take time out of their schedule to submit and validate reports.

The problem isn’t just the administrative process either. The system still requires you to register and log in before you can view a report. This makes it difficult to link to issues from other sites. It would be a bit more tolerable if the system would at least keep you logged in when you check the box to do so. Countless sites on the Web manage to keep you logged in upon request whether you’re using Internet Explorer, Firefox, Opera, Safari, Konqueror, or even lynx, but the Internet Explorer feedback system can’t manage to remember Firefox users who ask to stay logged in. Users who submit information find that they are unable to edit most of that information once it is sent, which has led to several reposts of the same issues simply to make corrections.

The service that the Internet Explorer feedback system attempts to provide is very much needed in the web development community. Here is some of the work that needs to be done:

• Only require users to log in to submit content. Reports should be publicly viewable without registering an account.
• The login form should remember users when they select the relevant options. This is Web Development 101.
• The Validation form should allow users to check boxes of versions they have validated.
• Resolution status should be separated into two distinct status indicators: report status automatically determined by the user validation system; and a (non-final) version indicator of when the IE developers hope to address the issue, if ever. Users, not the IE developers, should decide whether or not an issue still warrants being listed as “Active”.
• No more “By Design” ratings. It is simply insulting when 6-0 users have verified the problem and it has a 5/5 average rating out of 10 votes. And when 8-0 users verify a problem with a 5/5 average rating out of 11 votes, “Won’t Fix” becomes questionable as well.
• Allow the report submitter to change any of the original details of the report.
• Provide a way for users to mark duplicate reports, maybe using some kind of voting system, and always provide a link to the original report when marking a duplicate.

It seems clear that the administration is incapable of adequately running the feedback system. This may be due to lack of dedicated resources, but that isn’t an acceptable excuse when it comes down to service quality for the users. I say turn the system over to the users. Let user content determine the status of reports. Let users correct reporting mistakes. IE developers should keep us up-to-date with their progress, but as long as it is a user feedback system, let the users decide what is still an issue and what the details of the issue are. At the moment, the company-run Internet Explorer feedback system feels as if it is designed and run by amateurs compared to the user-driven Bugzilla system. Microsoft needs to learn from the leaders in the field and deliver on their increasingly trite promises.

In the meantime, I will continue submitting content to the feedback system, despite the fact that it seems to be fighting me every step of the way. I encourage other users to petition Microsoft to improve the quality of their service by loosening their iron fist.

I have finished testing the CSS 2.1 and CSS 3 support in Opera 9.

Here are some of the major changes in Opera 9 as far as CSS 2.1 and CSS 3 support:

• Apparently full support for CSS 2.1 basic selectors.
• Corrected support for :active and :hover with universal selectors and the body element.
• Some fixes for margin and width properties.
• Elements can now properly overlap iframe elements.
• Much improved support for CSS 3 media queries.
• Apparently full support for CSS 3 basic selectors (from previously no support).
• Support for most form-related CSS 3 pseudo-elements.
• Some support for CSS 3 opacity property, although the support is somewhat flawed (for example, if you have an element with the same color for foreground and background and reduce its opacity, the text’s alphatransparency is rendered separately from the background’s, causing the text to be quite visible).

There isn’t much that I was personally disappointed about. There are still some issues with :before, :after, and :first-line, but they are no worse than the issues other browsers have with them. Counter scope is still handled incorrectly according to the current CSS 2.1 drafts, although the problem can be avoided by remembering to use counter-reset in the appropriate places. I would have liked :last-child support, but that’s in CSS 3 anyway. I still notice some slight positioning problems when dealing with very complex styles, although it’s difficult to pinpoint the exact source.

All in all, this release shows that Opera is continuing to make consistent progress in the area of CSS support, and it is certainly giving other leading browsers some strong competition. According to the Web Devout tables, Opera’s overall CSS 2.1 support has risen from 93% to 96%, compared to IE 6’s 52%, IE 7’s 54%, and Firefox 1.5’s 93%. Opera’s support for current CSS 3 changes has risen from 8% to 22%, compared to IE 6’s 10%, IE 7’s 13%, and Firefox 1.5’s 27%.

HTML and DOM support information will come later. Some improvements have been made in both areas.

Opera 9 has now been released. Some of the new features include a selective content blocker which can be used to remove banner ads and other unwanted content from webpages, support for BitTorrent distributed downloads, desktop widgets, and improved standards support. See the official changelog for more information.

I will begin testing and updating my standards support resource shortly. It appears as though many positioning bugs have been fixed. Although Opera 9 passes the Acid2 test, note that the test only covers a relatively small selection of features from the standards, and like other browsers, there are still known inconsistencies with the standards in Opera 9. I will post updates on my progress as I test its support.