The ICON element simply indents its text 1 inch and applies appropriate padding and spacing. The NOTE, SHORTCUT, WARNING, and TIP elements don’t need styles at this point because they have no content at all. In final production, they must be replaced with graphics.

  ICON {
     display:block;
     text:indent:1in;
     padding-top:9pt;
     padding-bottom:9pt;
     line-height:18pt
  }

The table items are a problem in CSS. CSS offers no row or column settings for its display element, and creating generic styles for building tables in CSS is nearly impossible. This task requires the flow objects of a more powerful style language, like XSL or DSSSL. The following is an approximation of a table, but CSS won’t be able to make it look quite right.

  TABLE {display:block;
     padding-top:9pt;
     padding-bottom:6pt
     }
  TBC {
     display:block;
     font-weight:bold;
     font-style:italic;
     padding-bottom:9pt
  }
  TH{
     display:block;
     padding-bottom:9pt
  }
  TBH {
     display:inline;
     font-weight:bold
  }
  TR {
     display:block;
     line-height:18pt
  }
  TB {display:inline}
  SN {display:block;
     font-size:10pt;
     padding-top:6pt;
     padding-bottom:6pt
 }

FIGURE elements are always centered on the page. The FIGREF element that actually places the figure picture doesn’t need a style, unless extra padding is necessary. The FIGREF will inherit the centering from the FIGURE element. The figure caption (the FG element) will also inherit the centering, and the FIGNUM will appear in bold.

  FIGURE {
     display:block;
     text-align:center
  }
  FG  {
  display:block;
  font-style:italic
  }
  FIGNUM {
  display:inline;
  font-weight:bold
  }

Eventually, we will be able to use styles like these to present complex XML documents in a browser with a minimum of difficulty. Changing styles with Cascading Style Sheets is extremely simple, making it easy to present documents in different formats aimed at different media. Although CSS doesn’t provide all the answers (as we saw with the tables), it provides enough structure to build a reasonably well-formatted XML document.

Pass 2: Toward a Cleaner DTD

The real test of the previous DTD will come as authors and the production department put it to use, stretching it and finding its weaknesses. Several significant weaknesses arose during the previous discussion but were overlooked for the sake of compatibility with the previous version. A second round, unhindered by the political need of compatibility, may improve the DTD to make it more extensible. Three areas could definitely use some structural improvements—the leaf structure, lists, and icons—and many elements could use friendlier names.

These improvements are mostly technical improvements that demonstrate some of the more interesting features of XML. They are not guaranteed to improve user productivity, however. Some users may find the older structures easier to understand. DTD developers will frequently need to compromise between a more elegant technical solution and a solution that users find friendly. Automated tools for entering information will help bridge that gap, but their acceptance may take a while.

Even though the ALEAF/BLEAF/CLEAF structure makes sense to a reader who can scan through it, it requires a considerably larger number of elements than a more generic leaf version might. A more generic structure would use elements that behave similarly but that aren’t labeled as A or B or C. Creating a generic leaf structure involves recursion—allowing an element to include another element of the same type within itself.

Recursion has several meanings in different contexts, many of which lead to endless loops. XML permits elements to include themselves in the list of accepted child elements, but it does not, for example, permit entities to refer to files that then refer to the original file. For most purposes, the following recursion is the practical limit of recursion in XML.