Website template, spring 2008
Over the years that I’ve been a web developer I have, like any other full-time developer, created a base set of files (a ‘template’) that allows me to get going quickly when I start a new web project. I should stress that this is not a design template, but a set of files and basic code that I find myself using all the time. I’ve decided to share mine in the hope it’ll be useful for someone. Please note that this is not a replacement for projects such as Blueprint. It’s the summation of all the experience and ‘best practices’ that I have learned in the last five or six years as a Web Standards and Accessibility conscientious front-end developer. It has no aim other than to help me produce the best possible website I can, in the quickest time that I can. Having said that, I’d welcome any questions or suggestions as long as they are polite
The directory structure
Is simple; the
Any files that are to do with site content (i.e., they are semantically relevant) will go into a folder that’s a sibling to the assets folder (in this case I have an
images folder, sometimes there are more, such as
Because it helps keep XML naming conventions in mind, all filenames are in lowercase.
I mainly use XHTML 1.0 Strict, because it enforces the strongest rules for good authoring whilst allowing a MIME type of text/html. All the code is in fact XHML 1.1 valid (once the DOCTYPE is changed), but because the W3C forbids the sending of XHTML 1.1 with a text/html MIME type, and because configuring the server to send the right MIME is often impractical, it generally stays as XHTML 1.0 Strict (occasionally I use Transitional). If you want to know more about the MIME type issue and associated caveats, I suggest reading The Autistic Cuckoo’s old but very relevant post about the issue: ”Content Negotiation”.
The XHTML itself is coded with the following in mind;
The page should linearise well. Which is to say that the page content comes first, the navigation comes last, and everything in-between should read sequentially in a way that makes sense when CSS is disabled. These points are essential for good accessibility and also help search rankings.
All mark-up should be semantically appropriate. If something is a list, I mark it up as one. If something is a table, I mark it up as one. But I don’t go overboard - I use mark-up in a way that adds clarity to the content, not simply mark-up that is ’semantically correct’. I could mark-up a paragraph of text as an
<ol> because a paragraph is an ordered list of words, but as the meaning is apparent and intrinsic in the
<p> element’s semantics, I’ll use a <p>. That’s the sort of thinking I mean by using mark-up appropriately.
The main CSS file is validated, and free from any hacks, but we still need to deal with IE’s bugs, so I use Conditional Comments to force Internet Explorer to load additional style-sheets. The means that IE and only IE will take the hit of loading the additional rules to make it behave and display correctly. Using Conditional Comments allows the main style sheet and the IE specific stylesheets to validate.
<body> tag has an
id assigned to it that is an xml valid conversion of the website URL (eg:
mattwilcox-net, because you can’t have a ‘.’ in the attribute value). The intention is to allow user-agents to apply custom CSS or JS based on that identifier. It’s a technique that may no longer be relevant, as I’d hope that Greasemonkey and other plug-ins work by URL rather than a body ID. Still, it’s an old habit and I don’t know enough to know whether to drop this or not. The class is to allow the CSS file to target an individual page; more on that later.
I try to keep semantically un-needed mark-up to a minimum. There’s very often no point using
id’s all over the place, or wrapping everything in a
div. Sometimes it’s impossible to achieve a visual effect without putting some code in there, but where possible I avoid it. This keeps file sizes down and encourages proper use of the Cascade in CSS.
I still use the organisational methods described in my post from two years ago ”Organising CSS, revisited”, though there are a couple of tweaks. Firstly we now have IE7 to deal with, so
screen_ie.css has become two files:
screen_ie7.css. Secondly, I’ve largely ditched
screen_extended.css because it was hardly ever used. Instead I put CSS3 (e.g.,
border-radius) and vendor-specific versions of CSS3 selectors (e.g.,
-moz-border-radius) straight in screen.css, and treat it as though it’s valid CSS3 as opposed to CSS2.
I use jQuery and a number of plug-ins, because jQuery is brilliant and allows me to enhance the behavior of the website without requiring me to jump through hoops. You can learn a lot about it over at jquery.com, I recommend you take a look.
In implementing JS I bare in mind Progressive Enhancement philosophy, so I do not alter the XHTML itself at any point, and I do not rely on the idea that JS will be enabled. I use JS to add niceness, not to provide mission-critical functionality. To that end the form validation and ‘date-picker’ and other effects are added niceties, proper validation occurs server-side in addition to the validation the JS performs.
As an accessibility enhancement I also make it so that clicking an internal hyperlink causes the page to scroll rather than ‘ping’, this allows a sense of scale and position that the normal browser behaviour does not. Also, at the end of the scroll a box will animate around the item that the anchor pointed to (in browsers that support
outline, a CSS3 property) - this makes it much easier to see where you ought to be looking.
General bits and bobs
I try to keep http requests as low as possible, so I make a lot of use of CSS Sprites. This is also why I have one large CSS file to display all the pages (as opposed to a style-sheet for each page). You can take a look at a couple of other tricks I sometimes use with CSS on my 2006 redesign post.
The homepage and the interior pages vary very slightly with the mark-up. On the homepage I have the website title as the
<h1>, but on other pages it is the page title that is the
<h1>, for semantic reasons as well as a bit of SEO.
I develop to WCAG 1.0 + Samurai Errata. This is the new, modern, accessibility guideline. It is superior to both WCAG 1 and WCAG 2. For this reason I do not use
<accesskey> any more, unless a client explicitly requires it (which is why you will find them commented out in the template).
You can download the template in ZIP format, or you can take a look at the template for a homepage and an interior page. Remember, these are my starting blocks. They are not about the design, they are not ‘finished’.
Special note I have recently been playing with the idea of using CSS templates in a similar way to Blueprint, and in these files you will find classes such as ‘float’ and ‘one-third’ in the HTML and CSS. These are entirely presentational, and to be utterly honest I do not like them. Playing with this technique at all is a conceit to the idea of getting a website out-the-door as fast as possible, but the price is having presentational class names in the mark-up. I may well ditch them. It makes me very uncomfortable to use them (which is why I’ve never liked Blueprint in the first place).