Dave Woods - Freelance Web Design Warwickshire

Debugging HTML and CSS

HTML and CSS is an art. Give the same design to different developers and the code they deliver will never be identical. This can cause a number of problems when developing a website and ultimately in tracking down problems. This article has been created, not to solve all HTML and CSS issues but to ultimately help designers and developers to track down those annoying little layout problems and to at least demonstrate how to isolate issues with their code.

Validate HTML

I’ve said it hundreds of times, if the HTML code that’s being read by the browser isn’t valid then it’s highly unlikely that what you’ll see will be consistent across all the standards compliant browsers.

More experienced web developers will generally design a site and then test at the end to ensure that there’s no tiny little glitches that have been missed. However, for beginners it is imperative that they test their site as they’re developing. The W3C Markup Validator is a vital tool for any developer and should be used during development to ensure that there aren’t hundreds of issues to fix once a site has been built. Fixing problems as they appear is much easier than trying to rework all your HTML code at the end of a project.

Validate CSS

Once you’ve ensured that your HTML is valid, it’s time to check that the CSS you’ve created is also valid with no spelling errors. It’s easily done and missing out a } or ; can have huge implications on your layout. You can check your CSS at http://jigsaw.w3.org/css-validator/ and is something I’d definitely recommend doing.

Needle in a Hay Stack

So you’ve validated the site but it’s still not quite appearing how you’d expect it to in one or more browsers. This is usually the situation that people find themselves in at the end of a project when they’ve built a site and are browser testing. They have lots of HTML and CSS and something is slightly out of place but there’s so much code that it’s almost impossible to know what to change. The ideal situation would be to have tested in each browser during development but starting again is pretty much out of the question at this stage. So how can I isolate that single bit of code amongst hundreds of lines of HTML?

Firefox Web Developer Tool bar

Firstly, for people using Firefox, the Web Developer Tool bar Extension is a priceless plug-in that can save a great amount of time. Outlining block level elements is probably the feature I use the most as you can instantly see where the borders of elements are and the spacing of these elements including the padding and margins although using the display topographic information can be just as useful.

Outlining Body Elements

But my problem is in Internet Explorer, I hear you cry. I’m sure there are other tool bars available for all browsers by now but I prefer a simpler approach when debugging.

Using CSS I apply the following:

div {
border: solid 1px red;

This will outline all divs within the page on all browsers so I can easily see where the edges of divs meet. This is extremely useful if you’re unsure whether paddings and margins are being applied or unsure what is forcing a div out of position. Exactly the same principle can be applied to other elements as well. However, you should be careful as this does add an extra couple of pixels to either side of the element it’s applied to so may knock your design out slightly, as long as you’re aware of this though then it can be useful in spotting the problem.

Isolating a Problem

If using the outlining body elements method didn’t manage to get you any closer to solving the problem don’t worry, there’s still an easier way to find out what the problem is without going through each individual part of the page and tweaking the HTML only to find that you still haven’t found the problem.

Well coded websites are usually divided up into separate sections. Whether this is by using div’s or by using id’s within body elements is irrelevant but most pages I deal with will have clear areas of code that are clearly defined.

Please note: At this stage, I’d recommend making a copy of your page as you’ll be removing lines of code from your page. Speaking from experience it only takes an accidental close of your HTML editor or a power cut to lose hours or days worth of work.

Once you’ve made a copy, start by removing large areas of your page. Start with areas that you’re pretty sure aren’t responsible for the problem. If the problem seems to be within your footer, try removing the header and then refresh the page. If the problem is still there, remove the navigation and so on until you’re left with just a few lines of code. Quite often I’ve found that a problem has been caused by an area of the page that I’d never have expected it to be and only by following this process of eliminating code have I tracked down where the issue is.

Now that you know that the problem is being caused by this area of the page it’s time to delve into the CSS and see what part of the CSS is causing the issue.

It may be useful to apply background colours to the individual styles you have left in your page. This can sometimes highlight a problem quite obviously with the padding and margins which may have been overlooked during an earlier stage. It may also show that there’s a problem with a mixture of block and inline elements which is quite common so this step makes those issues easier to spot.

I’d then suggest removing a complete CSS style and seeing what happens. If the problem is still there then try another CSS style. It shouldn’t take too long before you find which CSS style is causing the problem. Once I’ve highlighted the style that’s causing the problem, I’ll start removing one value at a time from this style. For example, remove padding and margins from this style, refresh the page and see if that solves the problem?

Eventually you’ll have tracked any problems down to one or two styles that may be conflicting with each other or that a certain browser doesn’t render quite as expected (I’m looking at IE when I say that) and a fix can be put in place.


Learning fixes for HTML and CSS problems will come with experience and initially you may need to ask for advise, but having the knowledge to be able to track down where a problem lies in the first place is certainly a skill that is easy to come by if you understand the process.

Do you debug HTML and CSS differently? Do you have a more efficient method? Please feel free to leave any comments.

One comment on “Debugging HTML and CSS