First thank you to those (many!) of you who contacted me to point out that this article and the pages it occupies are not compliant. I know. Redesigning sites which have been in existence for some time to comply with standards is a major job and one which we have not yet grappled with. 

In our defense we are not alone. A recent survey of the websites of member organisations of the W3C revealed that only 4.6% of the sites were standards compliant or, put another way, 95.4% ignored the very standards they are responsible for creating.

All I can resort to is the old adage beloved by parents - and obviously by W3C members also -  "Do as I say, not as I do!".

Becoming Compliant

What are the problems?

There are broadly speaking four areas where pages get into difficulty with standards compliance.

1. Failure to use Required Elements or Attributes

A common example is the failure to use alt tags on all images. Even spacer images used purely for layout purposes (though strictly speaking these should probably not be used wither!) need alt tags. In the case of these images the correct method is to simply use alt="", no text required but the alt attribute should be present.

Other frequent error here are the failure to use double quotes around attributes and the omission of closing tags.

2. Use of Proprietary Code.

This is code that has been supported by one or more browser but is not part of the WC3 specification.

Examples of this would be <nobr>, <marquee> and <blink> tags. Some recent browsers have even introduced new proprietary tags, such as the <q> tag introduced with NN6 for short quotes.

While these will work now in some or even all current browsers they could, and probably will, be dropped at any time in future versions and should be avoided.

3. Syntax Errors in HTML

There are lots of reasons why even those using wysiwig editors need to learn HTML and being compliant is one of them. Even those purists writing HTML by hand are not above becoming sloppy in their work and have, in the past, usually managed to get away with it. 

Over the years it has become clear that those posting at the OutFront forum about problems with browser compatibility almost invariably has problems in their HTML. There have been some pretty radical changes in what is and is not valid HTML, and a very considerable amount of the HTML in regular use is no longer strictly valid. Sure it works - for now, most of the time - but it won't always. since we will have to grapple with writing valid HTML sooner or later, it may as well be sooner.

There is no shortcut to learning HTML but here are a few common errors to look out for that will become increasingly important with the move toward XML and XHTML.

a. Failure to close tags

FrontPage in particular has a tendency not to close paragraph tags. Thus you will see:

<p>This is a paragraph.
<p>This is another paragraph.
<p>This is a third paragraph.

when you should see

<p>This is a paragraph.</p>
<p>This is another paragraph.</p>
<p>This is a third paragraph.</p>

While most browsers will infer what you mean by the first lines, they shouldn't have to and they will not always do so. 

An example of where this can break down completely is when you use percentages in a style sheet to size fonts in a paragraph. In that situation, because the initial <p> tag is not closed. the second paragraph will be rendered as a percentage of the size of the first, the third as a percentage of the size of the second. Unless your percentage is 100% you will rapidly progress to unreadably tiny text.

b. Overlapping tags

We have tended to get away with code like this:

<p>This is a paragraph with <b>some bold words</p></b>

Which should be

<p>This is a paragraph with <b>some bold words</b></p>

This is a particularly important error to be aware of with the increasing move towards of XML and XHTML where there is an absolute requirement that tags be nested correctly.

4. Use of Deprecated HTML Tags

A number of quite commonly used HTML tags are no longer part of the standard. None of these tags are valid HTML any longer and the presence of any on your pages will be a cause of compliance failure.

<applet>
<basefont>
<center>
<dir>
<font>
<isindex>
<menu> 
<s>
<strike>
<u>

Many of these were uncommon anyway, but some such as the <font> tag are still in wide use for styling text on pages (yes, including this one!).

Ideally all style elements should be removed from your HTML page and instead placed in a style sheet. Having said that, use of inline styles is valid. However the use of the <font> tag to style text is no longer correct. 

This if you want a sentence in green type, bold and in Arial, you could validly use:

<p style="font-family: Arial; color: #476442; font-weight: bold;">This is a green, bold, sentence in Arial</p>

However, especially if you are using a wysiwyg editor, you are far more likely to see:

<p><b><font color="#476442" face="Arial">This is a green, bold, sentence in Arial</font></b></p>

The better solution is to use an external stylesheet containing the line:

p.green {font-family: Arial; color: #476442; font-weight: bold;}

and you can now simply have:

<p class=green>This is a green, bold, sentence in Arial</p>

Browsers and Compliance
A page of links to browser downloads with notes about the standards compliance of each.

Making a Site Compliant
An account of the redesign of a site to comply with standards. Interesting and useful but in this case a decision was made not to be backwards compatible with older browsers, which may not be the right choice for everyone.

Validate your HTML
Links to a variety of online validation tools.

>> Part III - Creating  a Compliant Template in FrontPage

<< Part I - Introduction to Standards Compliance