Web Devout tidings

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 received a number of e-mails asking about the recent lack of updates, particularly regarding the rest of the Opera 9 information in the standards support tables. I have been rewriting the backend of this site and am preparing to launch it with several new articles and hopefully a large new section of the site if I can get it finished within a reasonable amount of time. I plan to finish the rest of the Opera 9 testing once that is more or less wrapped up.

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.

Tim Berners-Lee, the inventor of the Web, has been fighting for the idea of net neutrality, which he describes as the principle that “[i]f I pay to connect to the Net with a certain quality of service, and you pay to connect with that or greater quality of service, then we can communicate at that level.”

He has made two blog posts on the subject:

1. Neutrality of the Net
2. Net Neutrality: This is serious

The issue of net neutrality in the United States has largely turned into a partisan issue, with Democrats generally backing the idea and Republicans generally opposing it. Predictably, web service providers such as Google, Yahoo!, and Microsoft have supported the idea while telecommunications companies have opposed it, effectively arguing that they are due additional earnings from websites that profit on their infastructure rather than getting a “free ride”, despite already paying the often higher bandwidth costs.

The absense of net neutrality legislation may allow for telecommunications companies to manipulate the transfer speed for websites because they haven’t paid a new additional fee, because they are considered a threat to the respective telecommunications company’s business model (for example, if the company has interests in a certain video purchasing site, it may forcefully reduce the performance of competing websites), or for other arbitrary reasons. Supporters of net neutrality argue that the absense of proper legislation would create a two-tiered Internet that would compromise freedom and innovation on the Web.