On Custom DTDs

This is a very old article. It has been imported from older blogging software, and the formatting, images, etc may have been lost. Some links may be broken. Some of the information may no longer be correct. Opinions expressed in this article may no longer be held.

Dylan Parry wrote:

Of course, but validating against a custom, non-standards controlled DTD is a complete waste of time for HTML. That would be validation for validation’s sake. If you can’t validate against a recognised doctype then there is truly no point in attempting to create your own to cover your problems

Using a custom DTD can be very useful.

To use your own example, say you are working on a site that includes a lot of legal documents. You would like to mark up the clauses of each contract as an ordered list.

Occasionally, notes are interspersed between list items, interrupting the follow of the list. Example:

DRAFT CONTRACT
Acme corp will supply the following:
a. those that belong to the Emperor
b. embalmed ones
c. those that are trained
d. suckling pigs
e. mermaids
f. fabulous ones
g. stray dogs
h. those that are included in this classification
Note: Category h seems a little vague. Needs clarification.
i. those that tremble as if they were mad
j. innumerable ones
Note: How many of these should be supplied?
k. those drawn with a very fine camel’s hair brush
l. others
Note: Also seems too vague. This should be removed from the
contract or clarified.
m. those that have just broken a flower vase
n. those that resemble flies from a distance.

A good way to mark this up might be:

Draft Contract

Acme corp will supply the following:

  1. those that belong to the Emperor
  2. embalmed ones
  3. those that are trained
  4. suckling pigs
  5. mermaids
  6. fabulous ones
  7. stray dogs
  8. those that are included in this classification

Note: Category h seems a little vague. Needs clarification.

  1. those that tremble as if they were mad
  2. innumerable ones

Note: How many of these should be supplied?

  1. those drawn with a very fine camel’s hair brush
  2. others

Note: Also seems too vague. This should be removed from the
contract or clarified. See also item h.

  1. those that have just broken a flower vase
  2. those that resemble flies from a distance.

Although the item markers could theoretically be inserted with CSS (only Opera 5.1+ would be able to cope with the required styles — no other rendering engine has deemed CSS counters important enough to implement), it would be inappropriate — they are content, not style; they are referred to in the paragraphs.

So the “type” and “start” attributes here are required.

Validation is a useful tool. It provides us with an automated way of spotting code slip-ups. If we write

  1. the validator will notice the missing quote mark and tell us. A visual check in one or two browser might not reveal this error. So we want to validate our pages.

    One option is to simply use the Transitional DOCTYPE. Then our deprecated attributes will be allowed through. However, this won’t flag up “iffy” presentational markup, such as

    which could be better handled in CSS. (Note this is no use if you want to use attributes and elements that have never been in the real HTML specs, but are widely supported anyway, such as .)

    Another option is to use a Strict DOCTYPE but make a mental note to ignore errors about the particular Transitional attributes and elements you’ve decided to use. However, it you’re using these attibutes a lot, you may find a lot of these errors popping up in validation reports, which might hide the “real errors”.

    The third option is to create a custom DTD based on Strict, but with just the extra attributes and elements you need. That way, any errors that the validator flags up will be “real errors”, and anything that it allows will come up to your standards.