My XHTML/CSS creation process

Front-end development i.e. creating the XHTML/CSS for websites is my speciality. Yes, I also do PHP, MySQL and JavaScript but my heart lies with XHTML/CSS so much so that I’ve gotten to be quite good at it. Therefore, I thought it would be helpful to document how I typically go about creating the XHTML/CSS for a website.

In web design, I care most about the state of the (X)HTML, I like my sites to validate because it makes creating/fixing bugs easier.

Step 1. Create basic HTML website structure

I create a website structure usually with the following folders:

  • css
  • img – for images
  • inc – for include files
    • html – contains files such as header, footer
    • ajax – for any content that’ll utilise Ajax
  • js

This sets me off in good stead, having all the correct folders ready, I then set up virtual hosts in my local httpd.conf file (Apache configuration file) and create an entry in my Windows hosts file. This is so I can test files in a browser with a URL of say http://testsite/. This also allows me to absolute links throughout the site and plan for clean URLs from the start.

Step 2: receive/create the design in Photoshop format

Usually the web designer gives me the design which would probably constitute several Photoshop files each representing a different page type on the website e.g. the home-page, the news page, a form page, content page, a variant on the content page etc. At this point, I look through the designs and decide which parts of all designs are identical – usually these parts are the header with it’s logo and search form, the navigation/menu, the footer and maybe some other areas specific to that design. All the time, I’m looking at the Photoshop design I’m drawing out <div>s in my head of how the HTML should be structured. Sometimes, if the design is complex, I will draw out the <div>s really roughly on paper – I used to do that a lot more when I was still learning CSS but, now I do it less and less. Whenever I am attempting to teach someone the concept of CSS I’ll always draw the <div>s out on paper so people can see how they should layout in the code.

I’ve got to the point now, where I instinctively know if a <div> needs a containing/parent <div> or which order the <div>s need to go in in order for the design to work but this took me a long time.

Step 3: Create basic HTML/CSS

Once I’ve selected those sections I’ll build a base stylesheet (which I like to call global.css) that styles those <div>elements and everything contained in them. This stylesheet will sit on every single page and will be responsible for the majority of the site. I’ll create the HTML prior to the CSS though, it makes more sense to me to do it that way. The more correct content you can get into the website the easier it’ll be to write your CSS.


To speed things up as much as possible I have a pre-written CSS file called basic.css which holds all the stylings for HTML elements e.g. body, p, h1-h6, tables and forms.

The only things, I generally change from project to project in this basic stylesheet are some colours, borders/padding on forms, borders, background colours on tables and the padding/margin on block items like p, h1-h6, ul/ol/dl.


The basic.css file starts with by removing all browser default margin/paddings on all elements.

margin: 0;
padding: 0;

This is such an important step for me. As not doing this and relying on the browser to supply the padding/margin for your elements can increase the “CSS bugs” you’ll end up with. Internet Explorer, Firefox, Safari and Opera all have different default settings, some use margin, some use padding and so when you declare them yourself you give yourself so much more control.

padding: .5em 20px;

I usually take this basic.css and copy and paste it into the top of the global.css file. Depending upon how often forms are used throughout the site I may take all the form styles out of this stylesheet and put them in a separate forms.css file that is only attached to each page that needs it.

When it comes to actual page layout, I almost always end up floating the vast majority of <div>s on each page. This is called the Float (nearly) Everything method and it saves a lot of heartache. Floating is a really easy way to make sure your pages are vertically scalable i.e. stretchability lengthwise when text is resized. There will always be one element on a page that needs to float and as soon as you do you’ll need to clear some elements below at which Internet Explorer may get upset.

Writing style

I like my CSS to be as precise as possible. I use CSS shorthand throughout and I try to order my CSS in a logical way so it’s easy to read by myself and by others. I’ll also add a terms of content list at the top stating what’s in the CSS file and in what order plus some information on the file was last edited, by whom and what was added/removed.

Using a grid

Sometime the designer will give me the grid they design the site upon as a background image- this is a great tool and really allows you to line everything up as necessary. Sometimes it can be difficult to work out from a design if an element’s padding should be 20px or 15px and the grid helps with that.

Once I have the outside frame complete I move on to individual pages- I usually stick page-specific CSS in it’s on stylesheet e.g. news.css or home.css, or content-2col.css. Only items design items shared between pages make it into the global stylesheet.

Attach the stylesheets

I import my stylesheets. Why? I find it easier to them dynamically add every bit or page-specific one -line CSS declarations.

<style type="text/css">  
 @import url("/css/global.css");  
 @import url("/css/home.css"); 

Then if you wish to add extra CSS based on whatever you can.

<style type="text/css">  
@import url("/css/global.css");  
@import url("/css/home.css"); 
// IF/Switch statement 
@import url("/css/print.css"); 

Step 5: Fix browser-specific issues

Now I am so close to being finished, I check Internet Explorer 6 and 7 to see how the site looks. If there are problems, I’ll use Test styles feature of the IE Accessibility Toolbar. Problems usually arise around a lack of min-height (which I use a lot) in IE6, some unpredictable width/height issues, and margin issues in IE6. Since IE7 came along I’ve been very happy, I very rarely have to add any fixes for this browser and I think it’s great. I’ll get these fixes and put them in separate stylesheets e.g. ie6.css or ie7.css and attach them using conditional comments

Sprinkle with JavaScript

Once the page is done I’ll the add some JavaScript (when required). I’ll always try to used the DOM and make it unobtrusive so my XHTML remains clean.


That’s it, that’s my process – this usually takes 2/3 days with Step 3 taking up roughly 1 1/2 days. Note: it can take longer if I am making changes someone else’s XHTML/CSS as I often end up rewriting their entire XHTML and CSS to make it more efficient and cross-browser friendly which sadly, is often quicker than making simple edits which often produce IE problems if the CSS is bad.

9 responses to “My XHTML/CSS creation process”

  1. I’ve stopped using the global whitespace reset * rule due to the problems it causes with the appearance of dropdowns on some browsers. I now use the Yahoo! YUI reset.css (and fonts.css) to standardise the margins and padding for those elements that need it.

  2. Matthew, what problems have you noticed?

    I’ve sometimes seen on selects that they don’t seem to wide enough to accommodate their contents but that can be fixed by applying a right margin on the as so:

    select option{
    margin-right: .5em;

  3. How bizarre!

    I’ve not experienced them but I may check out the CSS files you mention to see what they offer.

  4. Nice, having a system is helpful but having it written down is really helpful. One little note on folder names though: “css” and “js” describe both the technology name rather than the purpose and at some point in the future you’ll probably find yourself putting content that isn’t css/javascript in those folders. Maybe something like “style” and “behaviour” (or an abbr. of) would make for more stable URIs. W3C mentions this point at, which is basically a hugely bloated version of what you wrote.

  5. Excellent point Duncan. I never thought of that but it’s true.

    Tomorrow, I’ll start changing folder names!

  6. I’ve stumbled across your site, I’m looking for some research material for my junior to bury her head into and you’ve some great articles for up-and-coming developers. So, much kudos.

    On a side note, anyone reading the above and wondering what the fix for ie6 min-height is:

    height:auto !important;
    height 400px;