Updates appear at the end of today’s Report.
Note: Within a few days of reading this post and related gripes, Sijtsche Smeman, who helps maintain the W3C CSS validator, fixed the bug. Now that’s service. If you feel as grateful as we do, say so.
{Update: We inferred logic where there was none. The W3C has not changed the behavior of its validation service per the rationale explored below. The service is simply broken. Presumably it will get fixed. Meanwhile, many valid CSS sites will be incorrectly labeled invalid. Don’t start redesigning just yet.}
The W3C’s CSS validation service has changed the way it interprets CSS authoring practices. Many sites that were designed valid no longer validate. The change in behavior affects sites that use the box model hack to compensate for the incorrect CSS implementation in versions of Internet Explorer for Windows prior to IE6.
There are thousands of such sites out there — all designed by people who wish to harness the power of web standards yet can’t afford to produce sites that are visually broken in the older versions of IE/Win used by hundreds of millions of consumers.
The sudden change does not invalidate all CSS sites; it does not change the way browsers display your site; and in some cases, if you wish to regain validation, you can work around the new problem with a minimum of effort and expense. {Or just ignore it. See the update at the top of this Report.}
The box model hack was the first and is still among the most popular methods of designing once and publishing everywhere without fear of delivering an unusable or displeasing layout in browsers with less than stellar CSS compliance. It works by taking advantage of a CSS parsing bug in those older browsers. Specifically, as most readers know, it inserts an aural media declaration into the middle of a screen-oriented CSS rule:
voice-family: "\"}\"";
voice-family:inherit;
Old browsers don’t understand this declaration. So when they encounter it, they stop reading the rule. Newer, more compliant browsers skip past the aural media declaration and continue to read the rest of the rule. In this way, you can feed old browsers an incorrect value that their broken CSS implementation requires, and feed newer, better browsers the correct value within the same rule. Designers typically use this hack for one of two reasons:
It’s a hack, to be sure, but its publication and dissemination some years back enabled designers to finally start using CSS for layout. (Before that, there was no sense in even attempting CSS layout unless you were designing for an Intranet of Opera or Mozilla or IE5/Mac users — or “designing” a non-commercial web page in a loosey-goosey manner, where you didn’t have to answer to a client, and didn’t much care what the page actually looked like from one browser to the next.)
It’s fair to extrapolate that without this hack or similar sleights of hand that followed it to market, even die-hard standards fans might still be stuck using tables for layout, lest their work break for hundreds of millions of Internet Explorer users.
The man behind the hack, Tantek Çelik, is Microsoft’s representative to the W3C’s CSS working group. He is also the development lead for Tasman, which was the first standards-compliant rendering engine to be used in a commercial, mainstream browser. And he consulted on A List Apart’s first CSS layout, back in February, 2001. In short, he is a friend to standards-based design.
Tantek’s box model hack was the final step in convincing tens of thousands of web professionals that it was safe to design with web standards. (The first step, of course, was getting new browsers to support standards fully and correctly.) For three years, the hack passed the W3C’s CSS validation tests with flying colors. Now, in many cases, it fails those same tests.
The sudden invalidation {actually an incorrect report that a valid site is invalid} does not affect every site that uses CSS for layout. For one thing, obviously, it only affects sites that use the box model hack. For another, the validator only cries foul if you designate a specific media type such as “screen,” “print,” or “projection” while linking to or importing your style sheet. You will have no problems if your site uses methods like these:
<style type="text/css" media="all">@import "/c/mystyle.css";</style>
<link rel="stylesheet" href="/c/mystyle.css" type="text/css" media="all" />
But the validation service will choke on your style sheet if it designates a specific media type, as in the examples shown next:
<style type="text/css" media="screen">@import "/c/mystyle.css";</style>
<link rel="stylesheet" href="/c/mystyle.css" type="text/css" media="projection" />
You would use media="all" if you want the same style sheet to be used by browsers, handheld devices, and printers, as well as in Opera’s “kiosk” mode. In this setting, the W3C’s CSS validator does not have a problem with the box model hack’s aural media declarations, presumably because it assumes such declarations are intended to control presentation in an audio browser.
By contrast, you would use more specific media types — the ones that now cause validation trouble for box model hack devotees — if you wanted to feed different devices presentations tailored to their needs, which is the practice the W3C recommends.
For instance, A List Apart uses one style sheet (media="screen") to control onscreen presentation, and another (media="print") to control print. ALA was valid when redesigned a few months back but the validator declares its CSS unkosher (at least when using the conventional method of linking a site to the validation service).
If ALA used one media="all" style sheet to avoid validation problems, then folks would be stuck printing sidebars and other page elements they don’t need, and type would be sized for the screen instead of the printer. If ALA used media="all" on its primary style sheet to avoid validation problems and a separate (media="print") style sheet for printers, the print style sheet would attempt to merge screen styles with print styles, resulting in printouts that were (a) mostly unusable and (b) varied from one browser to the next, as each browser valiantly attempted to combine incompatible CSS rules into a coherent whole. (We know because we tried it.)
If you use the box model hack, and if you don’t intend to deliver specific alternative presentations to printers, handheld devices, or other alternative environments, switch to media="all". If you publish via a dynamic system (custom CMS, Blogger, Movable Type, etc.), or even if you simply use old-school Server Side Includes, you can make the change in 60 seconds or less, and get back to worrying about more essential stuff, such as your client’s request to make the logo bigger or his insistence that you use GIF images instead of text for every word on the site.
If your CSS layout avoids using padding and borders, and if you don’t set text sizes using scalable CSS keywords, you don’t need to use any hack at all. The zeldman.com December 2003 redesign uses a background image to establish content areas and eschews padding and borders, hence no hack is needed to control the overall layout. But the zeldman.com design uses scalable CSS keywords, which do require a hack in order to avoid wrong-sized text in older versions of IE/Win, hence zeldman.com’s CSS no longer validates (when linked conventionally).
You can use em-based text instead of CSS keywords, thereby avoiding the box model hack, but if you wish to avoid the many problems that come with ems-based text, you’ll need to do extra work.
If your layout requires padding and/or borders and/or CSS keywords, and you need to support specific media types, then you’ll have to set aside time and a budget to move from the box model hack to some method that doesn’t throw the W3C validator into conniptions. Tantek’s mid-pass filter seems not to disturb the validator according to our pal Douglas Bowman, who has switched to this method for many of his projects.
After we published the 12:00 edition of this Report, Dave Shea informed us that the W3C’s CSS validation service was known to be broken. If you want to trick the broken validator into behaving correctly, “a really easy fix is to side-step the document parse tree and have the validator just check the file itself.” Send the validator a direct link to the style sheet and it validates. Send it the normal validation link and the same style sheet does not validate.
There used to be a lot more words here, when we thought the W3C was deliberately changing the rules on the very designers and developers who have been most supportive of its goals and recommendations. We were fair and balanced in what we said. But there is no need to preserve most of it.
We based what we said on the assumption that the W3C knew what it was doing when its service began declaring that thousands of CSS sites were invalid. If it’s simply a mistake that they’re taking a long time to fix, all it means is that they are human and that they rely on overworked volunteers who could probably use a helping hand.
We’re leaving the bulk of this Report online so designers and developers have somewhere to turn or something to point to if their clients start worrying about reported (but nonexistent) CSS validation problems on their sites.
Dave Shea elaborates on the previously mentioned method of tricking the broken validator into providing a correct report. This may be worth doing if you are working on a new style sheet and need to be certain that it validates.
Ethan Marcotte is toiling away at an alternative box model hack that seems to avoid triggering the broken behavior in the W3C CSS validator. We admire the gumption and creativity, but we think this is a waste of energy. We don’t need to switch from one valid CSS hack to another in order to win merit badges from a busted validation service; we need the W3C to fix its validator.
Some folks think the new behavior is correct. After all, aural styles don’t belong in a screen style sheet. We thought the same thing ourselves when we first wrote this Report; we were even willing to accept it as the kind of logic a W3C geek might follow to the bitter end, regardless of the practical consequences to thousands of existing websites. But our man on the inside assures us that in this case, the W3C is not pursuing logic for its own sake. (And the fact that you can trick the validator into operating correctly proves what our man says.) It’s not a new feature, it’s a bug. As such, it should be fixed immediately, lest those who are new to standards-based design become turned off to the whole thing and retreat to table layouts and font tags.
Craig Saila claims that the W3C validation service’s failure to correctly interpret CSS layouts that use the box model hack proves “why, if at all possible, CSS hacks should be avoided.” We don’t think it proves any such thing. The box model hack isn’t broken; the validator is. If this unfortunate situation illustrates anything, it’s that the W3C needs to rethink how it spends its money.
Web professionals around the globe rely on the W3C’s validation tools to ensure that their work is correctly authored. Practically speaking, these tools constitute the entirety of the W3C’s professional outreach program. They’re the only parts of the W3C most of us interact with on a daily basis. Tim, help us out: spend a few bucks making sure these tools work.
If, despite membership fees of $50,000 a head, the W3C can’t squeeze out a budget to cover the maintenance cost of its validation services, then we humbly ask the volunteers who maintain this tool to roll it back to a previous version. For as far as we can see, the only difference between previous versions and the newest version is that they worked and this doesn’t.
More highlights may be found in our Essentials Department.