Changing stylesheets in midstream

[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.]

4 thoughts on “Changing stylesheets in midstream

  1. argh I used an example

    <a id=”foo”>

    in the above comment but it appears you need to quote markup in comments here, so actually the example has exactly the effect in teh comment system as it had when it was inflicted on teh w3c recommendations, most of the first comment gets spurious underlining on mouseover

  2. The code silliness was really just a minor annoyance compared to the major breakage inflicted by the change in other areas.

    Most noticeable was that the files were edited in place to use xml syntax.
    So in particular but as they were served as text/html they were parsed as html which means that all following text until (typically) the end of the paragraph was inside the a element, this was made worse by css styling that made all such text (virtually the whole document for mathml) styled as links with random runs of text showing underlines as you mouse over the text.

    This habit of using XML syntax passed to an HTML parser is completely broken and it’s a shame to see the W3C using it so extensively on their site.

    Perhaps the most annoying change was that they made the files invalid, arbitrarily changing the doctype to xhtml strict from html4 transitional without actually changing the attributes within the document to use strict markup.

    As the editor of a spec that has been through dozens of public revisions over 12 years, every one of which was served as valid html, it was not amusing to find without warning that the document had been made invalid by the w3c of all people.

    But they were all just bugs that could easily have been fixed. However the other thing wrong with the new design was that (by stated intent) it made the REC track documents integrated into the website. This was highly unfortunate, especially as that added logos for various companies to the spec, but it also added lots of non normative, unreviewed text (in sidebars) which had been physically edited into the html file of the recommendations themselves. that’s not really acceptable, a standards track document should be self standing.


  3. I’m going to resist the temptation to correct the typo in David Carlisle’s first comment, since it illustrates so effectively the problem he’s discussing. (In the source, the second paragraph begins “Most noticeable was that the files were edited in place to use xml syntax so in particular <a> but … ”)

    Thank you also for pointing out that the links in don’t point to the beta-site versions of the specs; that makes it rather difficult to inspect the proposed new style, since the dates on which the new versions were prepared seem not to be documented anywhere. One might think, or hope, that just modifying the short-form URI to point at instead of might succeed, but those currently return the documents from the main site.) This looks at first as if the Communications Team were determined to hide all the evidence of the reformatting, but presumably it’s nothing so sinister, just an artifact of the process by which the reformatted documents were prepared and then withdrawn. As has been pointed out, the W3C site is rather complicated, and it may have been faster and simpler to handle the rewrites or redirects (or whatever method was used) using a method that affects both and Still, it does seem unfortunate, because it makes it harder for people to examine the proposed changes and note and fix problems.

Comments are closed.