If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

This page is for those who know HTML, but might be unaware of the standards involved in future-proof XHTML and the philosophy behind the separation of meaning and presentation.

Separating meaning and presentation

HTML was never meant to be used for presentation, but user-agents incorporated elements that formatted text and developers found ways to manipulate layout. With the power of CSS it is now no longer necessary to style using HTML and meaning (HTML) can now be completely separated from presentation (CSS).

There are a number of benefits to this - it should greatly decrease file sizes, it has the flexibility of a central style sheet that applies to the entire website rather than an individual page and it should also produce pages of much greater accessibility.

Following this philosophy basically means you shouldn’t style anything within the HTML. Tags such as font or attributes such as bgcolor should not be used. Even the border attribute inside an img tag is no longer valid in XHTML 1.1. This shouldn’t be a problem - there is no styling that can be done in HTML that can’t be done, and done better, with CSS.

It isn’t just about taking away the presentation from HTML, the application of meaning means specific HTML tags should be used when appropriate. For example, h1, h2 etc. should be used for headings - you should not just use CSS to make fonts larger.

A good guide is to see if a visual browser, with its default styling, presents the document well without a style sheet.

Tables should not be used for layout - tables are designed to display tabular data. This is perhaps the most difficult technique for experienced HTMLer’s to get used to as it completely changes the way the HTML has traditionally been structured in the past. This approach greatly reduces the size of the page and, due to the resulting linear code, it becomes much more accessible.

Read the Layout page in the CSS Advanced Tutorial for more on this.

Tags

In XHTML all tags should be lowercase and must be closed. For those tags that do not have closing tags (such as br and img), they must close themselves with a ‘/’ at the end (such as <br />). Note that there should be a space before the forward-slash.

The markup must be well formed, with elements properly nested (for example, <strong><em>this</em></strong>, not <strong><em>this</strong></em>).

All documents must have html, head, title and body elements. They must also start with a document type declaration.

The body of the document should start with p, h1, h2, h3, h4, h5, h6, div, pre, address, ins or del.

Attributes

All attributes must also be lowercase and their values in quotation marks.

Minimized attributes are not allowed (such as <input type="checkbox" checked />). Traditionally minimized attributes must be given the value that is the same as the name of the attribute (such as <input type="checkbox" checked="checked" />).

The name attribute is no longer valid (except in form elements) and should be replaced with id.

The target attribute is not a valid attribute. Praise be. It was daft anyway.

The alt attribute in the img tag is compulsory.

Accessibility

The reasons for making web pages accessible to users with disabilities are quite self-evident. Not only is it moralistic, but it will also benefit our future as web users grow older and the acuteness of the senses degenerates. Accessibility isn’t just about accommodating people with severe disabilities, it is about making it easier for a great number of people with minor (predominantly visual) impairments.

There are increasing legal implications such as the introduction of ‘Section 508′ in the US that makes a (half arsed) attempt to enforce certain accessibility initiatives and in the UK, all government websites must reach a specified degree of accessibility. How long until similar legislation is applied to general commercial websites, as it is for buildings?

If you follow the above practices, your HTML should already be highly accessible to users with disabilities. There are further initiatives that can make your web pages even more accessible (for example, see the Accessible Links and Accessible Forms pages) and it really isn’t that difficult.