C H A P T E R  18

Validation

Why You Should Validate

Validation is a frequently requested enhancement. Clients ask me to add a W3C validation logo to their pages to indicate that they have employed a competent web designer. Validation enables web designers to take pride in their accurate coding. There are also practical reasons for validating, as follows:

• Validating is another way to troubleshoot obscure problems. The designer can save time and avoid frustration by validating before testing a page in the various browsers.
• It ensures that your pages are correctly coded so that browsers do not produce odd results.
• It ensures that search engines will not be blocked by your minor coding errors.
• Disabled users will be able to access your pages. Small coding errors can baffle an automated screen reader.
• Mobile devices have reduced versions of the browsers; they cannot cope with the errors in non-validated sites.

The DOCTYPES for HTML5 and XHTML5

To validate an HTML5 page, the DOCTYPE must be set to one of the following:

For HTML5

For XHTML5

lang=en specifies the English language.

Logos

If a page has an accessible data table, the page must be in HTML4 or XHTML 1.0 because screen readers (at the time of writing) cannot read HTML5 tables properly (see the associated validations logos for HTML4 and XHTML1.0 in Figure 18-1).

HTML4 and XHTML 1.0 Logos

When an HTML4 or XHTML 1.0 page is validated, you are entitled to put a certificate of validation on the page to prove to your clients that you are capable of correctly coding web sites to the latest standard. You can also download a logo for a validated CSS2 style sheet. For HTML4 and XHTML 1.0, you were able to choose a logo in blue or yellow. The HTML4 and XHTML 1.0 logos are shown in Figure 18-1.

Figure 18-1. These downloadable logos are available from the W3C validator

The HTML5 logo is a bit different. We’ll look at that next.

The HTML5 Logo

Figure 18-2 shows the HTML5 logo that was released in January 2011.

Figure 18-2. The HTML5 validation logo

Currently the HTML5 logo does not indicate that W3C is the authority providing the validation. You will need to state this on your page.

The HTML5 logo is available in several sizes and several configurations. The W3C logo web site is pretty but confusing. It is found at http://www.w3.org/html/logo/

The Solution for a Verifiable HTML5 Logo

The HTML4 and XHTML 1.0 logos came complete with the HTML code so that users could click on the logo and receive verification that the page was genuinely validated. At the time of writing, the HTML5 logo did not have this safeguard; a webmaster could cheat and embed the HTML5 logo to pretend that the page was valid.

Meanwhile, I have devised some code to overcome this deficiency. The code can either eliminate the need to dynamically embed the HTML5 logo, or you can call it from your images folder. Enter the code shown in bold in Listing 18-2 at an appropriate place on the web page; you do not need my permission to use it.

If you would prefer to load the image from an images folder in your root folder instead of from the W3C web site, download the 64-pixel logo into your images folder, and then use the following alternative code snippet (verifiable-code-2.html):

If you prefer a smaller logo, change every instance of 64 to 32 in the code snippets. You will need to download the 32-pixel version of the logo to enable the second code snippet to show the small logo.

Using the W3C Validator

TheW3C validator and the HTML5 logos are currently in different folders and on different pages in the W3C web site. Also, a W3C logo without the necessary code does not signify that a page is valid. Hopefully these omissions will be remedied by the time this book is published.

I strongly recommend the W3C validator. Figure 18-3 shows the interface of the W3C validator, which is accessed at http://validator.w3.org.

Figure 18-3. The W3C validator’s interface

When you open the W3C validator in a browser, you see three tabs: Validate by URI, Validate by File Upload, and Validate by Direct Input. The following tips will help you to decide which tab you should choose:

• If your page has already been uploaded to a web host, choose the first tab, and either copy and paste the page’s URL into the Address field or type it in; for example, http://www.mywebsite.co.uk/myhomepage.html.

  Click the Check button and wait for a few seconds. Eventually, a report will appear.

• If the page is not yet uploaded to your web host, click the File Upload tab, browse to the file for the page on your computer, and load it. Then click the Check button.

  Or click the Validate by Direct Input tab and paste the page’s entire markup in the text area provided. Then click the Check button.

Figure 18-4 shows a successful markup.

Figure 18-4. A page of markup validated successfully by the W3C validator

Figure 18-4 shows the successful validation of a page of markup that was pasted into the text area. If the validation gives one or two warnings, they can be ignored because they refer to the fact that the validator is experimental and that utf-8 is assumed automatically. The warning is not about your page.

If the validation report has a green header, then your page is valid. If it has a red header, then you have one or more errors. I think this is a poor choice of colors for accessibility because the most common form of color blindness is red/green. Regardless, the following section reviews some of the errors and suggested workarounds.

The earlier validators for HTML4 and XHTML 1.0 checked for correct code style and for markup errors. The HTML5 validators are only concerned with markup errors. Because HTML5 is backwardly compatible, it will accept any of the earlier styles and the validator behaves accordingly. For instance, the HTML5 validator will accept <meta charset=utf-8>, <META charset="utf-8">, <meta CHARSET=UTF-8 />, or any combination of those styles. However, it will not validate <meta charset=utf8> because the missing hyphen is bad markup.

Some Typical HTML5 Validation Errors and How to Fix Them

Compared with validating HTML4 and XHTML 1.0, HTML5 documents result in fewer reported errors because the HTML5 validator only looks for bad markup; it does not check code style.

If the header of the validator’s report is red, the list of problems and suggested solutions will appear below the red header.

You may be alarmed to see a large number of errors listed in a red-topped report. Don’t worry, the validator always reports many errors when only a few exist in reality (many of the errors reported are duplicates).

The following sections describe some typical validation reports and the appropriate fixes.

A W3C Validation Report Found the Following Three Errors

The following is a snippet of the HTML5 markup that was submitted to the validator. I have added line numbers in parenthesis for instructional purposes only.

The first part of the validation report was as follows:

Don’t let the report baffle you, but start to clear away the warnings and some of the duplication as described in the following four steps.

1. All warnings were removed from the report because they apply to the validator, not to the document.
2. I removed all references to XML because they duplicated the previous error messages. The following is what remained of the first section of the report:
   Line 10, Column 23: Consecutive hyphens did not terminate a comment. -- is not
permitted inside a comment, but e.g. - - is.
<!--[if lte IE 8]><!--conditional Javascript added-->
<!--[if lte IE 8]><!--conditional Javascript added-->
 Line 13, Column 3: Bogus comment.
<![endif]-->

   The report stated that consecutive hyphens are not permitted within a comment. We know that consecutive hyphens in a comment are correct, so what was the problem? The validator sees the conditional block of code as a comment. This is correct because it begins with <!-- and ends with -->. The report should have said you cannot have comments within comments.

3. So, I moved the comment outside and above the conditional comment and tried validating again. The amended markup is shown next.
   <!-- conditional Javascript added -->
<!--[if lte IE 8]>
<script src="html5.js" type="text/javascript">
</script>
<![endif]-->

   This validated successfully; only error number three remained, as follows:

   Line 38, Column 42: Bad value 88px for attribute width on element img: Expected a digit but
saw p instead.
    title="Valid CSS!" alt="Valid CSS!" /></a>Syntax of non-negative integer:
One or more digits (0–9). For example: 42 and 0 are valid, but -273 is not.

   Looking at the markup, it is clear that a silly mistake had been made, as shown in bold type:

   <p><a href="http://jigsaw.w3.org/css-validator/"><img src="images/vcss-blue.gif"
width="88px" height="31" title="Valid CSS!" alt="Valid CSS!"></a>
<span class="small"><br><br>Markup Validated by the World Wide Web Consortium</span></p>
4. The last section of the report said it saw a letter “p” instead of a number. Image widths in the HTML markup must be numbers only. The 88px would be fine in a CSS style sheet, but it was bad markup when included in an HTML page. After removing the px, the whole page validated successfully.

Video Files Can Produce Validation Errors and Warnings

An HTML5 file that played a video was submitted to the validator, which reported fourteen errors and two warnings. The two warnings were ignored because they related to the validator and not to the page. Twelve of the errors were the same—twelve ampersands were written as '&'. The validator recommended that the ampersands be changed to the entity &. Using Find and Replace, the twelve ampersands were changed to entities. The page was then tested in several browsers to check that it still functioned correctly; fortunately it did. The page was again submitted to the validator. The report then gave only two errors, as follows:

I commented out the </embed> tag and then the page was tested in browsers, and then re-submitted to the validator. This time, the only error was in line 20, where an attribute was missing in the <object> tag.

The validator recommended either a data or a type attribute. First, a Mime type was matched to the video, which was a Shockwave file.

A quick search on the internet revealed the MIME type for a Shockwave file; it was entered into the code, as shown in bold.

The amended page functioned properly in the browsers and it validated successfully.

Byte Order Mark Found

Microsoft Expression Web is one of the programs that creates markup that can produce the mysterious warning, “byte order mark found”.

A byte order mark (BOM) is a sequence of bytes embedded in utf-16 pages. It makes sure that your utf-16 documents are read correctly by web browsers. Unfortunately, MS Expression Web, by default, adds a BOM to utf-8 pages or on PHP pages where a BOM is unwanted.

In MS Expression Web, to prevent a BOM being included in new pages, follow these steps:

1. Click Tools and select the Page Editor Options dialog box.
2. On the Authoring tab, look under New Documents.
3. Then under Add a byte order mark (BOM) to new utf-8 documents with these file extensions you will see a list of file extensions.
4. Clear the box next to each file extension that you would prefer not to have a BOM.

To remove a BOM from an existing page, do the following:

1. Open the document in Expression Web.
2. In Code view, right-click anywhere, and then click Encoding.
3. In the Text File Encoding dialog box, clear the box labeled “Include a byte order mark (BOM)”.
4. Save the page and upload it; then re-validate it.

Rare or Unregistered Character Encoding Detected

If you see that error message, the meta tag containing the text encoding has an error in it. The markup should read:

<charset=utf-8>

Most likely you omitted the hyphen in utf-8.

Regarding PHP pages, the inclusion of some PHP code is a common reason for the “rare or unregistered character” error message. To validate a page that contains PHP, the charset must be windows-1252, as follows:

<charset=windows-1252>

Validating Accessible Data Tables: HTML4 and XHTML 1.0 Validation Errors and Solutions

For the blind and partially sighted, any data tables must appear on an XHTML 1.0 or HTML4 page. This will be necessary until screen readers can correctly read HTML5 data tables with three or more columns.

The following section deals primarily with errors on HTML4 and XHTML 1.0 pages, but some will also apply to HTML5 pages. Only a small number of validation errors are mentioned in this section because there are 447 known errors and space is limited (visit the w3.org web sites in the following tip to see all the known error messages).

You may be alarmed to see a large number of errors listed in a red-topped report. The validator finds an error at the top of the page then it cascades down the report repeating the same error report many times, sometimes using different words. For instance, when validating a page that has errors, these errors may be repeated lower down in the report as XML parsing errors. Just ignore them and they will go away when you correct the errors nearer the top of the report.

Some of the Most Common Validation Error Messages

The following are some of the most common validation error messages:

OMITTAG NO: This precedes a common error. Look for elements that are not closed properly.

Line 78, Column 9: end tag for "html" omitted, but OMITTAG NO was not specified.

The end tag for the opening <html> should appear on the last line of the page. I had omitted the tag.

The <p> tag: The most common XHTML 1.0 error is a <p> with a missing closing tag </p>.

Closing tags: Some closing tags in XHTML 1.0 are different from plain HTML4; <br /> must be used instead of <br>. The tag <br /> is called a self-closing tag. All XHTML 1.0 <meta> tags and <img> tags must be closed with a forward slash like this …" />. The report states closure errors like this:

Line 38, Column 10: end tag for "ul" omitted but OMITTAG NO was not specified.

That means that the closing tag angle bracket > was omitted in an HTML4/XHTML 1.0 page, or the closing tag in an XHTML 1.0 or an XHTML5 page should have been /> and not >.

When closure errors are reported, several errors will cascade through the report even though there is only one closure error. Fix the error and the cascade will vanish.

An element that is not open: The opposite of a closure error.

Line 87, Column 12: end tag for element "SPAN", which is not open.

This may mean that you removed an inline tag such as <span> earlier in the document but forgot to delete its closing element lower down in the page.

Lowercase: Remember XHTML 1.0 markup must be all lowercase. The validator will expect to see lowercase.

Incorrect nesting: Some tag errors may be described as being in a place that is not allowed. You may have intermingled <ul> <li> elements with table elements <tr> <td>. The error message will say something like:

Line 33, Column 32: document type does not allow element "li" here.

Nesting with inline elements: In the next example, the validator is saying that block element tags like <ul> cannot be enclosed within a <span> tag.

Line 52, Column 4: document type does not allow element "ul" here.
        <span class="list">
        <ul>
        <li>he Haven provides sheltered housing companionship in retirement</li>
        <li>Thirteen purpose built units for single or double occupancy</li>
        </ul>
        </span>

The <span> tags should be eliminated and the class should be inserted into the <ul> tag.

Other not allowed here errors are the result of surrounding a block element with an inline tag. For instance, surrounding an unordered list with <span> tags, <b> tags, or <strong> tags.

Deprecated tags and attributes: The error report will find deprecated elements that are no longer acceptable in HTML4 or XHTML 1.0; for example:

Line 32, Column 7: there is no attribute "CENTER".

This means that center is no longer acceptable in HTML markup; a style sheet must be used to center elements.

Examples of the W3C validator’s more helpful explanations:

Line 137, Column 19: value of attribute "ALIGN" cannot be "ABSBOTTOM"; must be one
of "TOP", "MIDDLE", "BOTTOM", "LEFT", "RIGHT". align="absbottom" width="199"
height="231">

Some attributes such as align are no longer valid for lining up text with images, only top, middle, bottom, left, and right are acceptable.

ALTs: The validator will report "alts" missing from images.

Some reports are not clear; for example:

Line 25, Column 39: document type does not allow element "li" here; missing one of
"ul", "ol", "menu", "dir" start-tag . <li>Home page<li>.

I had forgotten to put a forward slash in the closing tag like this </li>.

Some misreporting occurs like the following example:

Elements not allowed here
Line 23, Column 9: document type does not allow element "h2" here; missing one of
"object", "applet", "map", "iframe", "button", "ins", "del" start-tag . <h2>some
heading text was here</h2>

I looked at line 23 and could not find the error; the h2 element was properly closed. I then looked at nearby lines and found that on line 22, there was no closing </p> tag for a <p> element. Errors that are wrongly reported can usually be fixed by looking above and below the reported line for an unclosed <p>.

The .nu HTML5 Validator

The alternative validation web site is http://html5.validator.nu

I found this reasonably easy to use, but its reports are not as informative as the W3C validator’s. The W3C validator actually uses the .nu validator as part of its code-scanning process. I tend to use only the W3C validator, but that is probably because I am so familiar with it. You should not let my personal preference prevent you from exploring the .nu validator. It is constantly being improved, and its interface is self explanatory. The uncluttered interface is shown in Figure 18-5.

Figure 18-5. The .nu validator’s interface

At the time of writing, the .nu validator did not provide an HTML5 logo. You will need to go to the W3C logo site for this. Then you will need to add my code snippet to enable users to check the validation.

Validating CSS2

Go to http://jigsaw.w3.org/css-validator/, where you will find an interface similar to the HTML validator, but with the heading CSS Validation Service.

• If your CSS page has been uploaded to your web host, type in the URL of the CSS style sheet you want to validate using this format: http://www.mywebsite.co.uk/mystylesheet.css.

  Click the Check button and wait for a few seconds. Eventually, a report will appear.

• If the CSS page is not yet uploaded to your web host, click the File Upload tab, browse to the file for the page on your computer, and load it. Then click the Check button.

  Or click the Validate by Direct Input tab and paste the CSS page markup in the field provided. Then click the Check button.

If the markup fails to validate, you will be given hints about the errors. If it validates, you will be offered a logo to put on your page.

The following example report can be baffling:

The outset border color on the menu’s 3D buttons has been set the same as the background color. These warnings can be safely ignored, but if you wish, the error can be eliminated by a slight change to the outset border color to make it different from the background color.

CSS style sheets will also fail to validate if the same color is used for text and for the background of a gradient. For instance, if the background is white with a green background gradient and the text is also white. The validator ignores the gradient and compares the true background (white) with the text (white). It will report this as an error.

CSS3 Validation and Vendor Specific Errors

To validate a CSS3 style sheet, go to http://jigsaw.w3.org/css-validator/.

• If your CSS page has been uploaded to the web host, type in the URL of the CSS style sheet you want to validate using this format
• http://www.mywebsite.co.uk/mystylesheet.css.

  Click the Check button and wait for a few seconds. Eventually, a report will appear.

• If the CSS page is not yet uploaded to your web host, click the File Upload tab, browse to the file for the page on your computer, and load it. Then click the Check button.

  Or click the Validate by Direct Input tab and paste the CSS page markup in the field provided. Then click the Check button.

The CSS3 validator will report errors for any vendor specific items in the style sheet; that is, items such as -mozkit- and -webkit-. This is what you would expect because the vendor-specific items are not W3C recommended; the validator’s role is to check for conformance with W3C recommendations. Such errors will continue to be reported until browser vendors support CSS3 and dispense with their vendor-specific hacks. By all means play with CSS3, but perhaps you should forget about CSS3 and its validation logo on clients’ web sites until these hacks are no longer required and when IE 7 and IE 8 have finally expired. Meanwhile, use CSS2 on clients’ web sites.

For example, a CSS style sheet was tested and the validator gave a report with a red banner. The content of a typical failure report is shown in Figure 18-6.

Figure 18-6. The CSS validation report for a CSS3 table

I examined the code that was submitted, and found the error and the warning, as shown in bold text in the following:

In line 2 the semicolon after the 5px should have been at the end of the line as follows:

td { border:1px black solid; padding:0 5px 0 5px; }

The warning about the fifth line recommends that a text color should always be specified, as well as a background color. The line should have been:

table tr:nth-child(even) { background-color: #C8F0F0; color:black; }

When the corrected CSS code was re-validated, it gave the congratulations message, as shown in Figure 18-7. The banner in this case was green.

Figure 18-7.The W3C validator for CSS3 showing a successful validation

A validation logo for CSS3 was not available at the time of writing, but as you can see in Figure 18-7, you are offered the traditional CSS logos and the code that enables users to verify the validation.

Summary

In this chapter, you discovered how useful validation is for troubleshooting and for ensuring your code will function properly on all sorts of devices. A code snippet was provided to embed an HTML5 logo that enables users to check that the page has been genuinely validated. You also learned that the reports received from the validator can be rather cryptic and that some practice is necessary in order to become familiar with their meanings and the solutions.

In the next chapter, you will learn how to deal with some of the problems that arise when designing web sites. Troubleshooting is an important aspect of web development; the tips and short cuts in the next chapter will save you time and frustration.