Validating HTML Documents with A Real Validator

To validate HTML documents with A Real Validator, you must first add the HTML files to a project. You can do this using the Add Files option of the File menu or by dragging and dropping the files from Windows Explorer. With either method, you can use the Ctrl and Shift keys to select multiple files.

To quickly add all HTML documents in a directory (and all sub-directories), drag the directory from Windows Explorer onto the project view (the top half of a child window) in A Real Validator. Hold down the Ctrl key when dragging and dropping from Windows Explorer to validate the HTML documents right away.

With your HTML documents in a project, you can validate them using any of the following methods:

  • Double-click on the file in the project view.
  • Right-click on the file and select Validate.
  • Select one or more files and then select Validate from the Actions menu.
  • Select one or more files and then click the Validate button on the toolbar.
  • Select one or more files and then press F2.

Use the Ctrl and Shift keys to select multiple files.

Copyright © 1999 Liam Quinn. All rights reserved.


Choosing a DOCTYPE

According to HTML standards, each HTML document requires a document type declaration. The "DOCTYPE" begins the HTML document and tells a validator which version of HTML to use in checking the document's syntax.

If standard HTML does not meet your needs but you still wish to gain the benefits of HTML validation, see the section on using a custom DTD.

The following DOCTYPEs are commonly used:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

This declares the document to be HTML 4.0 Strict. HTML 4.0 Strict is a trimmed down version of HTML 4.0 that emphasizes structure over presentation. Deprecated elements and attributes (including most presentational attributes), frames, and link targets are not allowed in HTML 4.0 Strict. By writing to HTML 4.0 Strict, authors can achieve accessible, structurally rich documents that easily adapt to style sheets and different browsing situations. However, since many browsers lack full support for style sheets, HTML 4.0 Strict documents may look bland on common visual browsers such as Netscape Navigator 3.x.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">

This declares the document to be HTML 4.0 Transitional. HTML 4.0 Transitional includes all elements and attributes of HTML 4.0 Strict but adds presentational attributes, deprecated elements, and link targets. HTML 4.0 Transitional recognizes the relatively poor browser support for style sheets, allowing many HTML presentation features to be used as a transition towards HTML 4.0 Strict.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC-html40/frameset.dtd">

This declares the document to be HTML 4.0 Frameset. HTML 4.0 Frameset is a variant of HTML 4.0 Transitional for documents that use frames.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

This declares the document to be HTML 3.2. HTML 3.2 is well supported by most browsers in use. However, HTML 3.2 has limited support for style sheets and no support for HTML 4.0 features such as frames and internationalization.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

This declares the document to be HTML 2.0. HTML 2.0 is widely supported by browsers but lacks support for tables, frames, and internationalization, as well as many commonly used presentational elements and attributes.

Copyright © 1998-99 Liam Quinn. All rights reserved.


Using a Custom DTD

Many documents on the Web use non-standard elements such as EMBED and non-standard attributes such as the LEFTMARGIN attribute on the BODY element. These documents will not validate against standards like HTML 3.2 or HTML 4.0, but validation is too important a tool to be ignored for this reason.

To validate documents with non-standard extensions, one can write a custom document type definition (DTD) that defines the elements. Extending an existing DTD to handle non-standard extensions can be relatively easy. As an example, we will extend the HTML 4.0 Transitional DTD to support the proprietary BGSOUND element and the proprietary LEFTMARGIN, TOPMARGIN, MARGINWIDTH, and MARGINHEIGHT attributes of the BODY element.

  1. Start by downloading the HTML 4.0 Transitional DTD and saving it to your computer.

  2. Open the file in a text editor. If you're using Windows and the line endings are messed up, try using WordPad.

  3. Adding attributes is easiest, so we'll start by adding the margin attributes to BODY. Search for "BODY" in the DTD and you'll find the following definition:

    <!ELEMENT BODY O O (%flow;)* +(INS|DEL) -- document body -->
<!ATTLIST BODY
  %attrs;                              -- %coreattrs, %i18n, %events --
  onload          %Script;   #IMPLIED  -- the document has been loaded --
  onunload        %Script;   #IMPLIED  -- the document has been removed --
  background      %URI;      #IMPLIED  -- texture tile for document
                                          background --
  %bodycolors;                         -- bgcolor, text, link, vlink, alink --
  >

    We want the value of each new attribute to be a number of pixels, so we'll use NUMBER as the value type. Each attribute is optional and takes no default value, so we use #IMPLIED as is done with the BACKGROUND attribute. The preceding definition then becomes

    <!ELEMENT BODY O O (%flow;)* +(INS|DEL) -- document body -->
<!ATTLIST BODY
  %attrs;                              -- %coreattrs, %i18n, %events --
  onload          %Script;   #IMPLIED  -- the document has been loaded --
  onunload        %Script;   #IMPLIED  -- the document has been removed --
  background      %URI;      #IMPLIED  -- texture tile for document
                                          background --
  %bodycolors;                         -- bgcolor, text, link, vlink, alink --
  leftmargin      NUMBER     #IMPLIED  -- left margin --
  topmargin       NUMBER     #IMPLIED  -- top margin --
  marginwidth     NUMBER     #IMPLIED  -- left and right margins --
  marginheight    NUMBER     #IMPLIED  -- top and bottom margins --
  >

  4. Now let's add our BGSOUND element. The BGSOUND element is comparable in many ways to IMG or BASEFONT, so we'll add it alongside these elements as "special" text markup by changing

    <!ENTITY % special
   "A | IMG | APPLET | OBJECT | FONT | BASEFONT | BR | SCRIPT |
    MAP | Q | SUB | SUP | SPAN | BDO | IFRAME">

    to

    <!ENTITY % special
   "A | IMG | APPLET | OBJECT | FONT | BASEFONT | BR | SCRIPT |
    MAP | Q | SUB | SUP | SPAN | BDO | IFRAME | BGSOUND">

    The HTML 4.0 Transitional DTD later defines these "special" elements as inline elements, which seems right for BGSOUND.

  5. We'll start a new heading for proprietary elements and define our new element by adding the following:

    <!--================== Proprietary Elements ==============================-->

<!ELEMENT BGSOUND - O EMPTY            -- background sound -->

    We could add this pretty much anywhere, but we'll put it just before the "HTML content models" heading since that's nearby our comparative element, BASEFONT. Like BASEFONT, BGSOUND is an empty element, which means that it doesn't take an ending tag. The hyphen just after BGSOUND in our declaration indicates that the start tag is required. The O indicates that the ending tag is optional. EMPTY says that BGSOUND does not contain any elements, which means that the ending tag is in fact forbidden.

  6. We now need to define the attributes that our new element will take. For simplicity, we'll assume that we only want to use the SRC and LOOP attributes.

    To decide how to define the SRC attribute, we'll look at the definition of the IMG element's SRC attribute:

    <!ELEMENT IMG - O EMPTY                -- Embedded image -->
<!ATTLIST IMG
  ...
  src         %URI;          #REQUIRED -- URI of image to embed --
  ...
  >

    BGSOUND's SRC attribute also takes a URI as its value, and it also should be required since the element is useless otherwise.

    There is no other LOOP attribute in HTML 4.0 Transitional, but we know that we want to take values that include INFINITE, -1, and 4. The value type CDATA (character data) covers these values. The LOOP attribute is optional and it defaults to a value of 1.

    So we have the following attribute definitions:

    <!ATTLIST BGSOUND
  src         %URI;          #REQUIRED -- URI of sound to play --
  loop        CDATA          1         -- number of times to play the sound --
  >

  7. Now save the DTD as "HTML4plus.dtd" (or anything else you like) and upload it to the Web. You can then tell the validator to use your custom DTD by using the following DOCTYPE:

    <!DOCTYPE HTML PUBLIC "-//LRQ//DTD HTML 4.0 Plus//EN"
   "http://www.example.com/HTML4plus.dtd">

    (Replace "LRQ" with your initials and "http://www.example.com/HTML4plus.dtd" with the URL where you put your DTD.)

    For offline validation with A Real Validator, copy your DTD to A Real Validator's "sgml-lib" directory. Then open the "html.soc" file (or "xhtml.soc" for an XML/XHTML DTD) with a text editor and add an entry for your DTD:

        -- HTML 4.0 Plus --
PUBLIC "-//LRQ//DTD HTML 4.0 Plus//EN" HTML4plus.dtd

Copyright © 1998-2000 Liam Quinn. All rights reserved.


Ampersands (&'s) in URLs

Another common error occurs when including a URL which contains an ampersand ("&"):

<!-- This is invalid! --> <a href="foo.cgi?chapter=1&section=2">...</a>

This example generates an error for "unknown entity section" because the "&" is assumed to begin an entity. In many cases, browsers will recover safely from the error, but the example used here will cause the link to fail in Netscape 3.x (but not other versions of Netscape) since it will assume that the author intended to write &sect;ion, which is equivalent to §ion.

To avoid problems with both validators and browsers, always use &amp; in place of &:

<a href="foo.cgi?chapter=1&amp;section=2">...</a>


Writing HTML in a SCRIPT Element

A common error occurs when writing HTML tags within a SCRIPT element:

<script type="text/javascript">
<!--
  // This is an error!
  document.write("</P>");
// -->
</script>

Technically, the first occurrence of "</" followed by any letter is considered the end tag for the SCRIPT element. While browsers are forgiving in this, authors should avoid using strings such as "</P>" in their embedded scripts. JavaScript allows authors to use a backslash to avoid ending the SCRIPT element prematurely:

<script type="text/javascript">
<!--
  document.write("<\/P>");
// -->
</script>

Copyright © 1998-99 Liam Quinn. All rights reserved.


Incorrect Nesting of Elements

Elements in HTML cannot overlap each other. The following is invalid:

<B><I>Incorrect nesting</B></I>

In this example, the B element is intended to contain an I element. To be truly contained within the B element, the I element's end tag must occur before the B element's end tag. The following is valid:

<B><I>Correct nesting</I></B>

Copyright © 1998-99 Liam Quinn. All rights reserved.


A Real Validator Help

If you have a question related to A Real Validator that is not answered by this help file, please contact liam@arealvalidator.com.

  • Validating HTML Documents with A Real Validator
  • Choosing a DOCTYPE
  • Using a Custom DTD

Common Validation Problems

  • Ampersands (&'s) in URLs
  • Writing HTML in a SCRIPT Element
  • Incorrect Nesting of Elements

Copyright © 1999 Liam Quinn. All rights reserved.