HTML Coding Standards
PLEASE NOTE: These guidelines are several years old. I will leave them here as a historical record, but I don’t recommend following them. I hope to get round to updating them one day. Maybe.
This is not a guide to writing semantically correct mark-up, nor does this guide document all of my HTML conventions, as these are evident in my latest projects. This is simply a guide for how I attempt to structure the HTML code of my projects.
Doctype & Content Type
Unless specifically requested, I always set the doctype of every site to XHTML 1.0 Strict. In the last few years I have standardised on this, and have never been confronted with a site that can only be built using a ‘lesser’ alternative. Using XHTML 1.0 Strict allows for a greater degree of separation between content, style, and behaviour.
I set the content type to text/html, with the character set of ISO-8859-1 or UTF-8 if the site is likely to need localising into languages that contain foreign characters.
I always place a standard set of tags in the head of any HTML document.
I always import CSS files in the head of the document through
The meta description and keywords should be present. The meta description tag is used by most major search engines in the listing of the site in question, and so should contain a short sentence describing the site. Meta keywords are usually ignored by search engines, but can be added anyway if desired.
I always place an id attribute on every body tag to uniquely identify it within the site. It can optionally also include a class to identify it within a section of a site. This is useful for CSS targeting. For example, an id of ‘home’ placed on the body tag means any CSS styles that start with the declaration #home will only apply to this page of the site.
I always immediately follow the body tag with a
<div> element with the id of wrapper, which contains all page content. This is to enable further control over page layout via CSS.
There are times when it is necessary to place a container outside of the wrapper. One example of this is where content is to be vertically centred, as in this case the wrapper is surrounded by a
<div> element with an id of horizon. The horizontal positioning of this element can be controlled by CSS.
My standard structure for an html page changes on a per-project basis, but it generally follows this convention:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 <html> <head> ... </head> <body> <div id="wrapper"> <div id="header"> ... </div> <div id="maincontent" class="threecol"> <div id="leftcol"> ... </div> <div id="centrecol"> ... </div> <div id="rightcol"> ... </div> </div> <div id="footer"> ... </div> </div> </body> </html>
For pages with multiple columns, the maincontent container can have a class that describes how many columns it contains, and any related information. A few examples are onecol, twocol, twocoleven, twocolwide and threecol. Placing these class names on the container allows specific CSS styles to be applied to different page layouts, which is advantageous for large site builds.
HTML Elements and Attributes
Any extra html attributes (e.g. class, id) that are applied to elements should have a structural meaning. I do not use any style-focused attributes that have been deprecated in HTML strict.
I only use inline styles within the html when elements are dynamically inserted into the page via server-side script, such as to apply background-images and positioning.
I tend to declare all attributes using double quotes ( “ ) rather than single quotes ( ‘ ).
I only use images in html when they are directly relevant to the content of the page. If an image is to be used for decoration only, I apply it as a background image to an element via CSS.
Whenever using an inline image, I use the following attributes:
- alt - description of the image for non-visual browsers
- title (optional) - extra information about the image
If an image is directly next to a title or content which accurately describes its content, then an alt attribute of
alt="" is acceptable.
I always attempt to set a width and height attribute on each image. This means when a page is rendering, even before the image has been downloaded it’s dimensions have been registered in the browser, reducing the amount of jumping of page elements.
tabindex and accesskeys
The main navigation of a page should use tabindex values to aid keyboard movement around the page.
Access keys should also appear on main page navigation. These access keys should follow a standard convention, and I generally number them 0-9. If further access keys are required for the main navigation, I use a-z.
The title attribute can be used on images and links for additional information, and I use it to where appropriate.
For main navigational items, the title attribute should really be used as much as possible, as it can also help provide additional information for search engine rankings.
All forms should use
<legend> elements, as they will not validate if you don’t use these elements.
I always add an additional class for any form
<input/> elements to identify them for styling. This class should be the same as the type attribute, for example
<input type="text" class="text" />
Classes & IDs
All class and ID names should have a semantic meaning relating to their content.
IDs should be used for unique page elements, and elements that re-occur throughout the site (although only once per page). For example, the header, footer, navigation, and main content sections should each have unique IDs that are consistent throughout the site.
Classes should be used for repeated elements within an individual page.
The combination of classes and IDs on individual elements is useful where generic styles (applied by the class) are extended by styles applied to each id.
1 2 3 4 5 6 7 8 9 10 11 <div id="boxes"> <div class="box" id="box1"> ... </div> <div class="box" id="box2"> ... </div> <div class="box" id="box3"> ... </div> </div>
My preferred method to correctly clear floated elements is to use a class of clearfix on the parent element. It should only be applied to this parent element, and not the floated elements within (unless they too require it).
I prefer this method to the float nearly everything technique.
To style horizontal rules in a cross-browser compatible manner, I wrap them in a div element:
<div class="hr"><hr/></div>. The horizontal rule can then be hidden with CSS, while the div element can be styled in a manner that all browsers can render correctly.
HTML tables should only be used for tabular data, not to position the content of the page.
Where possible I split table content using the
<tbody> elements to differentiate between the head and main body of table content.
<th> table heading element should be used to correctly mark up headings.
A class can be placed on every alternate row of table content to allow styles to be applied to these rows, such as a different background colour.
I only ever use HTML comments sparingly to separate and describe elements within page content, but I always remove them before the code goes live. For large, complex sites it is sometimes necessary to leave in HTML comments.
I validate all HTML through the W3C HTML validation tool.
I find that using the Firefox Web developer toolbar is the quickest way to do this, as it provides a keyboard shortcut to quickly test as you go along.
Removing all HTML validation errors is the simplest and quickest way to eliminate 90% of all rendering errors, and are usually the reason why browsers render page content differently.
I test every website to ensure it is accessible and functioning properly when accessed from a variety of different platforms, operating systems and browsers.
This is the list of web browsers that I support and test for on any normal project. Other platforms and browsers can be supported on request. (Please note, with new browsers and updates being released all the time, it is difficult to maintain a specific list of modern browsers.)
- Microsoft Internet Explorer: Pixel perfect in version 6 and 7
- Mozilla Firefox: Near perfect in versions 2+
- Opera: Usable in version 9.5+, and Opera for mobile
- Safari: Near perfect in version 3+, usable in Safari for iphone
- Google Chrome: Usable for beta
These legacy browsers each have less than 1% market share, and therefore I do not support them by default. They sometimes contain older, imperfect HTML rendering engines that take additional time to lay out a page correctly, as specific code must be written for them.
- PC Microsoft Internet Explorer: Version 5 and 5.5
- Macintosh Microsoft Internet Explorer: Version 5 and 5.2
- Mozilla Firefox: Version 1.5 and below
- Safari: Version 2 and below
- Opera: Version 8.5 and below
Screen readers and text-only browsers
I ensure that all sites are fully compatible with text-only based browsers and screen readers due to the ‘gracefully downgrading’ nature of these standards-based websites.
All pages are tested with CSS disabled to give a top level view of how text only browsers and screen readers will interpret the site ensuring that basic levels of accessibility are met.
This ensures that web users who use such browsers are able to browse and use your website even if they are lacking the software to render images or display certain styles.
These guidelines only outline how I create HTML, they do not describe how to write standards-compliant semantically correct mark-up. For more information on this, there are a number of helpful tools and websites:
The most important tool to use when creating HTML is the Mozilla Firefox browser. This allows you to install various browser plug-ins that help test sites.
- The Web developer toolbar for Firefox
- Firebug for Firefox
- Web Accessibility Toolbar for IE
- Web developer toolbar for IE