What I set out to do with this site was to demonstrate that it was possible to create a website that not only complied with web standards, but really exploited them. While writing my undergraduate dissertation, on the subject of electronic specification in design, I began to realise that there was a whole lot more to CSS than a simple skim across its surface revealed. I also came to a new understanding of what the separation of presentation and content meant, and what structured text was really good for.
My conclusion was that structure, in some ways, really has nothing to do with presentation and that what typographic design does, in essence (and in an idealised world), is transform the raw content (structure) into some final presented form. Design is a transforming process. This transformation is performed by describing the relationship between parts of the structure and graphic or other forms of presentation, and also with describing the relationship that those presented forms have with each other.
The route taken by HTML, as soon as presentation specific tags were introduced, was a strange and tangential one. The structure of a web page became inextricably linked with the presentation of that page, which meant that the transformational aspect of the design process was lost. The Holy Grail of computer-based structured document systems, that of truly independent structured content which was richly enough described to allow its presentation in a variety of media, was lost. Not only was HTML useless for presentation outside a web browser, but even across web browsers the interpretation of a page couldn't be guaranteed. Presentational tags were very often specific to one browser.
I'm not even going to talk about table-based layout. I think most web designers know all about that... What I will say is this: HTML tables, based on the CALS (US Department of Defence spec) SGML table model aren't much anyway. CALS tables are presentation oriented rather than data-oriented, because tables are a really complex subject, and I think no-one really wanted to have to deal with figuring out a way to describe tables abstractly. So actually using tables in HTML for layout isn't such a big peversion of their original use as some think it is. HTML tables are just shitty, full-stop.
CSS offered a way out of the presentational markup hole we'd all gotten ourselves into. What it allowed is this: the abstract description of graphic attributes and a way of mapping those descriptions onto HTML elements. CSS 2 extended these capabilities even further, allowing complex contextual relationships between elements and their graphic attributes to be built up. In some ways the name stylesheet is quite misleading, because the capabilities of CSS are light-years ahead of stylesheets in DTP applications in many respects, but treating CSS stylesheets as if they were DTP stylesheets is exactly the approach taken by all the WYSIWYG web tools. Attempting to treat CSS as something that it isn't simply replaces one set of mistaken assumptions with another, with Headings being turned into styled paragraphs by people used to the unstructured nature of DTP and numerous other little misunderstandings. How many classes do you need?
This site offers up a different model. It sticks to two principles: that markup should be as plain as possible, and that as few concessions to browsers should be made as absolutely possible. The standards have been my benchmark and I've often overlooked differences in rendering (for example, I've used position: fixed throughout the site). My design goal was to produce a site which was standards compliant, in spirit as well as letter, and which embodied good practice as far as issues like accessibility go. I suppose, if I'm honest, that my other primary goal was to use CSS as I thought it was intended, to describe the graphic relationships between text elements in an intelligent (read context-sensitive) way. Which, I'll admit, is also kind of like showing off.
For markup this means, in practice, that I've avoided class attributes wherever possible. By which I mean that I've only used them where I feel that HTML simply isn't rich enough to do what I need it to do. By and large this means I've classed a <div> tag to separate pages into functionally distinct areas. If I were using XML I would have a DTD which had a meaningful tag in place of that <div>. In visual terms, I've entirely avoided using GIF text. In fact, I've almost entirely avoided images everywhere. The exception is my photography section, which is currently empty...
In terms of DHTML it means that I've written code once and once only. I have written no cross-browser DHTML, I've simply coded to the DOM standard to achieve dynamic bits and bobs. I have a nasty suspicion that node.style.visibility is not quite what I'd hoped it was. I couldn't find that form of notation in the DOM standard anywhere but all the browsers support it so I'm assuming that it's fine until someone tells me otherwise and tells me the correct way to do it.
As far as possible I've used XHTML 1.0 Strict, because this is the simplest and most rigorous of the HTML standards. It also means that when modular XHTML is widely supported I'll be able to easily add or subtract things.
In terms of markup some areas, particularly the links section, are a right mess. This is because I wrote a Perl script to generate my cross-referenced links list, but did it in a way that wasn't really sophisticated enough for my purposes, so I've got to do it again, and I haven't yet. The Blog too is something of a dog's dinner, but there too I am in the process of planning my own tool for generating it.