Web Devout tidings


Firefox 3 CSS and HTML support information available

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.

2 Responses to “Firefox 3 CSS and HTML support information available”

  1. Daniel Says:

    That’s great data already, thanks.

    Even if HTML5 isn’t anywhere near Candidate Recommendation, it defines a small edge case your tables treat as error: Expanded form of empty attributes.

    Currently Gecko, WebKit and the latest Presto (Kestrel, Opera 9.5) represent as readonly=”" (DOM and CSS). Trident says it’s readonly=”true” (CSS only knows [readonly]).

    Accroding to HTML5, the epmty readonly attribute becomes readonly=”" and stays with the empty string.

    As said, this is true for every engine but IE. So I think your tables should treat readonly=”" as pass. As well as the IE7 mass testcase which tests for this case.

    Posted using Mozilla Firefox 3.0 on Windows.

  2. Steuard Says:

    The title formatting issue (allowing authors to manually specify line breaks using character entities) in Firefox seems to be challenging to solve. My understanding at the moment is that major changes to the basic structure of Gecko’s parser would be necessary to fix this (or perhaps a tremendously ugly hack). That’s not to say that it won’t happen, but it’s an intimidating prospect (and it may well be too deep a change to accept until the next major version change: after Firefox 3.x).

    But unfortunately, I think we’re stuck with the “strip newlines entirely” behavior based on the HTML spec. It’s spelled out pretty explicitly there. I quoted (and linked) the relevant bits when filing the currently active Bugzilla bug on this issue. The discussion in that bug (and the ones it links to) may give you some idea of the issues involved if you’re interested.

    Posted using Mozilla Firefox 3.0 on Windows.