[19 October 2009]

My evil twin Enrique came by the other day in a great state of excitement. There’s been a bit of a kerfuffle in some W3C working groups lately, he told me. As some readers will know, the W3C recently unveiled a new design for their web site. (Many people seem to want to call this a site redesign, but as far as I know most of the site was originally developed by individuals and working groups working autonomously, and outside the front page, the Tech Reports page, and the other pages maintained by the Communications Team, the site never had a consistent design to begin with. Surely it’s only a redesign if there was a design there in the first place?)

Almost all the comments on the new design appear to be positive — at least, they were until some spec editors and working group chairs noticed that the site redesign had included reformatted versions of their working groups’ current Recommendations, which the working groups had not looked at before and which proved, when examined, to be sub-optimal in some ways.

“Sub-optimal is putting it mildly,” laughed Enrique. “Some of the specs looked like night soil on toast. And some of the editors were fit to be tied.” Enough pain was expressed over the new look of the old specs, apparently, that after a couple of days the standard URLs for existing Recommendations were all reset, and no longer point to the reformatted versions. (The reformatted versions are still around — no one at W3C ever deletes anything, it’s a point of some pride — though you have to know what URIs to point to.)

One of the most visible problems is that in some specs, extra space was appearing before and after large numbers of hyperlinked special terms. “You know what it was?” chortled Enrique. “Some bright young thing at some bright young design agency seems to have thought a 20px padding would be a good idea for the CODE element. Do these people not know any HTML? Here, look at the stylesheet!” He pulled out a hand-held and showed me a rule from one of the new stylesheets (reformatted here for legibility):

h1, h2, h3, h4, h5, h6, ul, ol, dl,
p, pre, blockquote, code {
padding:20px 20px 0 20px;
}

He was cackling with malice now. “The stylesheet author seems to have thought that code was not for inline material but for indented blocks. Where do they get these people? And giving measurements in pixels is so dead-tree-oriented!”

“Now, now,” I said. “I’m sure you were a bright young thing once yourself.”

“Not me,” he returned brightly. “I was fifty-two the day I was born, and I’ve always been dumb as a post.”

“Two, actually. Odd, though,” I said. “When I retrieve the reformatted versions of the XML and XSLT 2.0 specs, I don’t see extra white space around code elements.” I retrieved the stylesheet with the bogus padding values for code; the rule now read

h1, h2, h3, h4, h5, h6, ul, ol, dl,
p, pre, blockquote {
padding:20px 20px 0 20px;
}

“Those bastards!” Enrique cried. “You mean they’ve fixed it? I was going to charge them big bucks to tell them what was wrong!” And he stomped off again in spluttering disappointment. I haven’t seen him since, but I’m not worried; he’ll get over it.

[The new W3C site is the result of a long design history, and really does appear to be an improvement, for the most part. It makes it much easier than the old site to find your way around (or so I believe — I knew the old site structure well enough that the new one just confuses me; I assume that will pass). The new look intended for W3C technical reports (i.e. Recommendations, Notes, Working Drafts, etc.) can be inspected on the beta site’s Tech Reports page, or the beta site’s version of the new Standards page. I haven’t yet decided whether I think the new tech report styling is an improvement or not, and if it is, whether it’s enough of an improvement to justify the disruption of restyling the entire body of existing Recommendations. I’ll be interested in readers’ reactions.

One thing is unsurprising: if you launch a new stylesheet on technical material whose authors and editors pride themselves on precision, you would do well not to make it public until they have confirmed that it is OK. And it would be smart, before you let them see it at all, and certainly before you make it public, to make sure the new stylesheet doesn’t introduce highly visible problems like 20 pixels of extra white space around every code element.

Live and learn.]