Jump to main navigation, main content

Archived entry | Matt Wilcox .net

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 smiley icon: smile

The directory structure

Is simple; the assets folder contains all files that are not semantic content. That means the JavaScript, the CSS, and the associated images for the design of the website itself. If something is in the assets folder it’s relevant to the behavior or visual style of the website, but not relevant to the content of the website. The assets folder itself is divided up into sub-folders by file-type. This helps keep things in predictable locations and stop the directories from becoming messy.

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 downloads or video).

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.

The entire site is designed and built so that it will work without JavaScript or CSS enabled, everything is done with a Progressive Enhancement mindset. Ideally the site should also work with CSS on but images off (which is why some elements have superfluous <span> tags in them, where possible I use the Shea Enhancement method of image replacement).

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.

The <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_ie6.css and 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.

The JavaScript

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.

I use a ‘lazy loading’ technique so that once the core JavaScript is loaded, additional JavaScript is only loaded on the pages that require it. If there isn’t a table in the page, then there’s no point loading the table-sorter plug-in, etc. A quick look at the JS files ought to show you how that works, I’ve commented them clearly enough to remind me what does what and why.

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).

The templates

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).


skip to comment form
  1. Neal G posted 1 days, 4hrs, 32mins after the entry and said:

    Nice article on a site template. How do you handle media types for css? A recently site I did I decided to put all my css (minus the if ie stuff) in one media="all" file and then target the various media types within that file (to cut down on requests) I try to avoid the "import" of stylesheets since it slows my development time down having my styles scattered all over the place.

  2. Matt Wilcox posted 1 days, 14hrs, 3mins after the entry and said:

    I have a stylesheet for each media type, so there's a screen.css (the main one) and a print.css. The media type is set on the media attribute of the link tag, you'll see it there in the head section.

    I find this is the best approach for me, but that may be due to how I approach print styles. I do not try and emulate the design for print, instead I essentially leave it as plain HTML, but remove superfluous bits and bobs (you don't need navigation on a print-out…), clarify other things (use CSS to output the URL after any hyperlinks), and otherwise that's it for styling. As I understand it (but I’m not sure) you don’t need to worry about http requests for media types, I think the browser only pulls the print stylesheet if it’s actually printing. At least, I have vague recollections of that, but I don’t know for sure and I’m not sure where to look to find out.

  3. Neal G posted 2 days, 6hrs, 44mins after the entry and said:

    I suppose one way to find out if the browser requests the stylesheet is to check your server logs. If you see that the print.css file is being requested for each visit, then you would know. I would seem logical for most browsers to ignore none screen type stylesheets until needed.

    Oh also I replied to your post on my site. Click the link in it and then click the "Create XML Error" error link on the example page (in internet explorer) to see what I mean.

From the archives

Other enteries filed under:

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.