I've been doing various overhauls of DWiki recently (a faster and better DWikiText to HTML renderer written by Daniel Martin (and hacked by me, so blame me for any problems) went in tonight, for example). As part of this, I've been looking at the HTML DWiki generates, running it past HTML Tidy and the W3C validator and so on. It's been a learning experience.

One of the things I've learned is that almost everywhere DWiki code and templates were giving <div>s an id="..." attribute, it was the wrong thing to do. In something like DWiki, id elements are dangerous.

The problem for a dynamic, template driven site is that every (hard-coded) id is a promise that that particular element will only ever appear once in a page. Any page. Every page. Better not forgetfully reuse an id-containing template twice in some page, even if it's the structurally right thing to do.

(For instance, the <div> around all of the comments on a page used to have an id. That seemed harmless until I thought about a) possibly showing comments by default on pages and then b) the blog view, which would show multiple pages in their normal rendering glommed into one bigger page. Kaboom!)

In DWiki's case, using id wasn't getting me anything I couldn't get with class; CSS styling can use either. This made my use of id more or less gratuitous, which just made my mistakes with it all the more wince-inducing. (The height of hubris was having a renderer, not even a template, put an id in its output.)

(I'm sure that advanced CSS tricks care about the difference, but DWiki's use of CSS is pretty simple.)

After a bunch of revisions, I now have id attributes in only five places, and at least two of them (the page header and the syndication feed information) are probably still mistakes. (They persist because I'd have to revise the CSS too, and I've already made enough big wrenching changes today.)

PS: changing the DWikiText renderer caused some fiddly little changes in the HTML of every entry in CSpace's syndication feeds. If your feed reader exploded as a result of this, you may want to get a better one. (With a very few minor exceptions, there should be no visual differences.)