Updated: 10th October 2011

High Quality HTML Markup.

With all the talk about standards compliance, semantic markup, progressive enhancement, cross browser compatibility and accessibility, writing HTML seems so much more complicated than the original idea of marking up content and it's easy to become overwhelmed. Hopefully this post helps clear up some confusion surrounding the topic. Perfect HTML/CSS/JavaScript has a number of properties described below. Some of these properties overlap. So for example if your HTML validates that will help with making it accessible. If you separate the responsibilities that helps you move towards semantic HTML. So they all work together to achieve high quality code.

Works across all browsers

Your web pages should render across all browsers in a similar fashion on both the desktop and mobile devices. It's impractical to achieve pixel perfect designs in every single browser out there so the first step is to identify which browsers you wish to support. As a starting point as of the time of writing the following browser families should be tested.


  • Internet Explorer
  • Firefox
  • Safari
  • Opera
  • Chrome


  • Safari on iPhone
  • Default Android Browser
  • Opera Mini

This list is somewhat arbitrary and based on global usage statistics (w3counter, statcounter, netmarketshare) so take it with a grain of salt. What you really should always do is look at the statistics for the website in question as the usage statistics will vary greatly depending on location and audience. However for new websites or as a starting point this list should cover at least 90% of website users. Also generally if your website renders and operates correctly on the above browsers its likely to work properly on many others as well.

I haven't gone into specific versions, in an attempt to try and make this article relevant for as long as possible however as a rule I recommend to always test on the latest version of each browser. For Internet Explorer I always test at least 2 major versions, so as of the time of writing IE9 and IE8. For Firefox I do the same thing however due to the recent rapid advancement in major Firefox versions it makes more sense to jump back to an older version. Currently I test in Firefox 7 and Firefox 3.5. As for Safari, Opera and Chrome due to their much smaller market share and higher chance of users updating I generally only test the latest versions.

For mobile devices it's probably a good idea to at least test Safari on the iPhone, the default Android browser and Opera Mini. Depending on how things evolve it may be necessary to expand this list in the near future. As of the time of writing I believe testing on these three mobile browsers will give you reasonable coverage. Of course the best thing to ensure your website works well on mobile is to build a mobile friendly version of your site. However short of that you should still make sure your website renders correctly and is basically functional on mobile devices.

HTML versions and validation

The first thing to address is XHTML vs HTML. There has been a lot of debate on this topic however due to the fact that we can't reliably serve XHTML with its proper MIME type application/xhtml+xml (doesn't display in IE8 and below) it seems most logical to stick with HTML. A common practice is to serve XHTML as HTML (text/html) which instructs the browser to treat it as HTML. In my opinion this is a bit pointless, if you are going to be serving as text/html you might as well author it as HTML. HTML5 is not yet an official recommendation so as of the time of writing HTML 4.01 seems the best approach. There will come a time when moving to HTML 5 makes sense however unless you need to specifically use something from HTML 5 such as the canvas element stick with HTML 4.01 for now. Also its best practice to use the STRICT doctype. So in summary HTML 4.01 Strict served as text/html is the best approach currently.

Regardless of what flavour of HTML you end up going with using the W3C markup validation service http://validator.w3.org/ you can ensure your HTML and CSS is standards compliant. Making sure your markup is standard compliant is always recommended as the standards will push you towards good practices and hopefully in time lead browser software companies to support the standards more completely.


The purpose of HTML is to mark up the document to give content meaning, and to some extent define the structure of its content. So basically a HTML document is just content given meaning and structure with the use of elements. So a header should be wrapped in a <hx> element. Tabular data should be in a <table> element. A list of items should be in a <ul> or <ol>. Paragraphs should be in the <p> element. You should be able to view the source on a web page and understand the meaning of the document without looking at how the browser displays it. Select elements to use based on the meaning they represent, don't select elements based on their default browser rendering. Build a semantic document and then use CSS to style it.

The problem with HTML is we don't have a large range of semantic elements to choose from. To get around this often there is little choice but to use <div> and <span> elements with meaningful id values to help bring meaning to content. <div> and <span> by themselves don't really have any semantic purpose and can be considered neutral, so by using an id such as <div id="header"> you can create meaning. div is just a "division of the document", while span is a "span of characters". When using <div> elements try and use them to break up the document into logical sections.

One thing you should avoid at all costs is using presentational elements such as <i> and <b>. These are purely presentational and add no meaning or structure to your document. Use CSS if you want text to be italic or bold.

Separate Responsibilities

Separate Responsibilities means that everything has its place. The content and document structure belong in the HTML files while the presentation/display belong in the CSS files. The functionality/interactivity belong in js files. This makes things much more neat and tidy and easier to update. It also helps achieve semantic markup, see last point.


Technically an accessible website is a website designed for people with various disabilities in mind. However this is a narrow definition and I find it more useful to think of accessibility as designing the website to be as accessible to as many people as possible. This includes people with disabilities but also people using old browsers or browsers with limited capabilities such as no Flash or JavaScript. By accessible we really mean the users can get access to all the content and also they can use all the features/functions.

The official standard for website accessibility is WCAG 2.0 http://www.w3.org/WAI/WCAG20/quickref/. However it is the greater concept of accessibility that is most important to strive for. Website content needs to be accessible to the widest possible audience. This includes:

  • people with disabilities
  • people with browser technology disabled (e.g. JavaScript, Flash, CSS, images)
  • people with older browsers
  • people using different browsers families (e.g. Firefox, IE, Safari, Opera, Chrome)
  • people with mobile devices

Following the WCAG 2.0 standard will obviously help with this goal. Try and conform with the official standard but the end goal is to make the content accessible to as many people as possible. So even if you get 3/4 of the way to following the standard that is better than nothing. And perhaps you will do some things not covered by the standard which improves accessibility, this is obviously good as well.

The standard is really focused mainly on people with disabilities. These people are important and catering to them should help with the other users listed above. So you can start with the official standard and try and meet AA level compliance. But also keep in mind the greater aim of making the site as accessible as possible to as many people as possible.

A good idea is to define the required level of accessibility for every website individually. So site A might require WCAG2.0 conformance, modern browsers and handheld devices support. Site B might require to work with modern browsers and for people with JavaScript disabled. Site C might require to work on modern and older browsers and for the iPhone. This needs to be decided on a site by site basis.

It's important to note that WCAG 2.0 is mandatory for all Australian government websites http://webguide.gov.au/accessibility-usability/accessibility/.

Graceful Degradation or Progressive Enhancement

These are two approaches to help achieve accessibility. Graceful Degradation means that you build your website and then afterwards you make sure it works when you start turning things off. So you disable JavaScript and test that all the content is still accessible and all the features still work. Then you disable Flash and check again, then CSS etc. Until you are left with plain old HTML. All the content should still be accessible and if possible all the features should still work with everything disabled. If at any point when disabling these technologies a feature stops working you have to modify (hack) the code to make it work.

Progressive Enhancement is really the opposite approach. You build the front end in HTML only and make sure the content is accessible and all the features work. Then you add a layer of CSS on top to make it look how you want, the same content and features still available. Then you add a layer of JavaScript to improve the user experience. But as you add layers you never actually add any new features which are essential to the user. So with this in mind to follow progressive enhancement you would build the HTML first and when that's working properly you add layers of CSS followed by JavaScript. Then you add any Flash components or any other third party add-ons which some users won't have installed.