Our Top 7 tips for better HTML
Our Top 7 tips for better HTML. Doctype, right elements, proper headings, semantic class and id-names, separate design and behavior from content and self clear floats.
“Doctype, right elements, proper headings, semantic class and id-names, separate design and behavior from content and self clear floats.”
1. Use a DOCTYPE
The DOCTYPE (or document type) tells the browser what type of document you are serving it. Without a DOCTYPE your code will never validate and browsers will render your page in [quirks mode]() which makes styling very difficult. To find out more about DOCTYPES, here's a [really good article]().
2. Use the right element for the right type of data
Using the right element for the right type of data is very important for accessibility, SEO, styling and structure. Do _not_ use tables for layout, use them for tabular data. Use lists for navigations (they can easily be styled to look any way you want and you normally only need the mandatory elements ul, li and a). Use paragraphs instead of just two line-breaks (
). Do not overuse the span- and div-elements; they are rarely needed and in most cases should be replaced with a semantically meaningful element.
3. Use headings properly
One of the most important elements for SEO is the heading-elements. If you google something that's in your title-element, a heading-element and the text, you will most likely get a pretty high ranking. Most people recommend not using more than one h1-element per document. I believe the only heading in a document that is over all other headings is the title of the page. Therefore I always put the title of the site at the top of the document in a h1, with a link back to home. Every other heading on the page gets a h2 unless of course it's a sub-heading to a h2 in which case it gets, you guessed it, a h3.
You can use the Firefox plug-in web developer's toolbar to view an outline of the headings in your document. I often do this and it gives me cause to think carefully about what is actually a sub-heading to something, and what is not. A lot of people seem to use h3 just because they think that heading has less meaning than some of the h2's on the page, but logically any h3 followed by a h2 is a sub-heading to the h2. If it really isn't then don't use a h3.
Here's what i consider a good document outline.
* My Blog * Navigation * Archives * By Date * 2007 * 2006 * 2005 * By Category * Art * Life * Comments * Some dude * Some other dude * Search * Poll
4. Use semantic class and id-names
If you're styling a table and you don't want the last row in it to have a border, a common class-name to use is "no-border". Try instead to think of _why_ this element has its styling, not just how it looks. A far better class-name would be "last-child" as that is preciesly the reason you do not want a border on it. Perhaps last-row is better, but I like to use last-child because of the pseudo-class :last-child (which of course does not work in IE).
I am very careful about my ID's and rarely use them in anything but div's wrapped around widgets/modules on the page. Instead of something like #left-col, #main-col and #right-col (which has a great deal to do with presentation (left/right)) use something like #navigation, #content and #sub-content.
Using things like "red", "no-border", "extra-margin", "bold" or "left" shows a failure to distinguish the presentation from the content. What if you want your red-class to be blue in a future design? That would make styling quite a pain.
5. Separate design from content
Never use inline-styles, never use bad class or id-names. When coding your HTML, never think about the design. Think of _what_ you are marking up. If you separate your design from your content enough there should be no problem to create a variety of different designs using the same HTML, just like [CSSZenGarden](http://www.csszengarden.com) or [exscale.se](http://exscale.se/styles/).
Completely separating your content from your design also allows for much leaner and smaller code. Something search engines and future coders on the same project really like.
6. Separate behavior from content
Just like you should separate your design (CSS) from your content (HTML), you should also separate your behavior (JavaScript) from your content. Never use inline-events (onclick, onblur etc). If you do that you're probably already developing your JS in an inaccessible way. Remember that not everybody has JS enabled, and always try to develop the core functionality with plain old HTML. If you want an image to open in a new window, don't add an onclick-event to the link that does it. Have the link point to the image, look for links pointing to images from your JS-file and then add onclick-events from a separate file. This way users with JS disabled will still have access to your content.
Use unobtrusive JavaScript, if a link is only used by JS, don't put it directly in the HTML-code but add it using JS. If a user with JS disabled enters your site and tries to click the link he will most likely get confused and frustrated.
Go ahead and read more about progressive enhancement and unobtrusive JavaScript. It's not difficult to develop front-end the right way.
7. Self-clear floats
When floating elements using CSS you have to clear the floats for the parent-element to wrap around its floated children. Before the :after pseudo-element there was no way (that I know of) this could be done without using an element in the markup to clear the floats. Sometimes there was no element so a
-element was commonly used.
With the :after pseudo-element you can clear the floats without an unnecesary div in your markup, like this:
As the undescore hack does not work in IE7 it will not read the height: 1% property and as inline-block does nothing in IE6 nothing will go wrong there either.
There you have it, no more .clear-classes or bloated code.
