Web Devout tidings

You can check it out here: Standards support information with Firefox 3.

In terms of the percentages, the improvements aren’t staggering. However, we now have access to display:inline-block, display:inline-table, more properties on generated content, white-space: pre-wrap, and negative z-index values, which are very welcome additions.

Some of the CSS improvements were parts of CSS 3 specifications that haven’t yet reached Candidate Recommendation status, so those improvements will not yet be listed in my tables. Some other features, such as most of the CSS 3 pseudo-classes, are nearing completion and will be rolled into Firefox 3.1, planned for release by the end of the year. I’ll provide a separate column for that.

I didn’t see any changes in the areas of HTML my tables cover. There were plenty of improvements in HTML 5 support, but that isn’t a Candidate Recommendation yet and thus isn’t listed in my tables. One noteworthy addition to HTML 4.01 is the support for ­ which allows you to control word hyphenation at line breaks. My tables currently don’t cover all of the entities.

DOM support information and Opera 9.5 information are on the horizon.

Update: I forgot to mention that there were some improvements in the HTML title attribute so that newlines and such are handled more consistently with the SGML standard. Unfortunately, Firefox doesn’t yet interpret newline character references as line breaks in the content.

See, when a user agent is parsing an SGML attribute value, it’s supposed to first collapse the whitespace following a certain algorithm, and then the character references get converted to their respective characters, which are placed in the final interpreted value as-is. So whitespace characters that are represented by character references should never be collapsed or converted to simple spaces. The referenced whitespace characters are considered part of the value itself.

Not only does Firefox not display the referenced newlines in the tooltips, but it actually displays nothing, as if the character reference were never there. Interestingly, if you right-click the element and click on Properties, it displays the title value as if the referenced newlines were replaced with spaces. No matter which way you look at it, Firefox isn’t doing what it should be doing.

An argument could be made for granting the user agent the right to collapse whitespace into a single space for its own reasons (for instance, if the value is being displayed in the status bar where you only have one line to work with). However, I can’t think of any excuse for collapsing it to nothing. As much as I’d like to see Firefox get a “Y” on all of those “(Core attributes)” rows, it just didn’t quite get there yet.

Update 2: To clarify, it appears that in the tooltips, newline references are being stripped out and carriage return references are being converted to spaces, which means they are being converted to their respective characters before the whitespace collapsing is applied. The HTML 4.01 spec isn’t very clear about this, but it’s assumed to inherit the attribute normalization rules from the SGML standard.

Yes, I know. I’ll be testing its standards support, too. Firefox 3 will be released this coming Tuesday, the 17th. I won’t have the standards support information done yet for either browser, but I hope to finish the CSS sections this weekend and put that up by Tuesday.

It’s browser testing season again. Since the first Firefox 3 release candidate has been released, I will begin testing its standards support and adding it to the site. As usual, I’m going to start with the CSS section and post an update when the initial test data is complete.

Rather than using a standard test suite, I prefer to write custom tests as I go. This allows me to get into the nooks and crannies of standards support, but it does take longer. Starting now, I’m going to save all of the test cases of bugs that I find, and at some point I’ll make those test cases publicly available.

My testing process usually works like this: I initially assume that everything with a “Y” in the last version also has a “Y” in the new version, so I’m not testing for regressions in my initial test data. This saves a lot of time, and I can add regression information later as it is found. Next, I go through each “I” and “N” and retest the browser’s support. Features that still have “N” support go by quickly, so it’s the “I” features that take the bulk of my time. The time it takes to complete a section depends on a number of factors, such as the demands by my day job, how scorching hot the weather is, and whether or not the pizza has arrived yet.

In regard to Safari 3 information, that will not be part of this test session. Adding information for a new browser from scratch is a ton more work than updating for a new version, and I want to get the Firefox information out there quickly. At some point, though, I’m going to bite the bullet and do the Safari 3 testing, even if the information isn’t very thorough at first (the IE, Firefox, and Opera information started off very rough as well). Until then, here are some sites you can check out for Safari (WebKit) support information: SitePoint Reference, Wikipedia, Quirksmode.

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%.

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.