Web Devout tidings

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.

The W3C Markup Validator is an excellent tool. If you’re a serious web developer, using the Validator is probably a routine by now. It’s also very reliable when it says you have an error. However, there are plenty of cases where the Validator will say a page is valid even though it doesn’t actually comply with the HTML or XHTML standard.

The Validator pretty much assesses two levels of compliance: it makes sure that your document is parseable using either an SGML parser (for HTML) or an XML parser (for XHTML), and then it checks your document’s compliance with the DTD specified by the doctype declaration.

However, the HTML and XHTML specifications demand additional restrictions that aren’t part of the DTD. For example, many values are specified as “number” values, even though in the DTD they are ultimately just CDATA, which can contain text. XHTML further limits the Validator due to the fact that XML DTDs aren’t as expressive as other DTDs and are unable to tell the Validator that, for example, form elements cannot be descendants of other form elements.

Here are a few test cases having fun with non-compliant but “valid” markup:

• HTML version
• XHTML version
• HTML div version
• XHTML div version

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.

If you haven’t heard, there have been several large wildfires in California this week. Governor Schwarzenegger declared a state of emergency in Butte County where several independently-started wildfires have destroyed homes and forced thousands of people to evacuate. There’s currently no evidence of malice, just a mix of unusually low humidity, high temperatures, and high winds for this time of year.

The largest wildfire in the area, called the Humboldt fire, made its way to the Butte College campus where the Web Devout server is located, eventually nearly surrounding the campus. Luckily, the firefighters had set up Butte College as their main base of operations, utilizing the campus’ firefighter training facilities and the wide open land that easily fit several hundred firefighters and engines from across the state. They also used the bulldozers on site to clear the dry grass in the margin between the college and the fire. Their efforts seem to have been a success: the fire is now receding from the campus, and none of the facilities were damaged.

The worst we suffered was a power outage at 3:35 PM Thursday when a couple of transformers blew. The electric company had restored power by the next morning. The Web Devout site was down during this time.

See the Associated Press article for more information about the fires.

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.