October 2, 1997

Stuart Culshaw, Michael Leventhal, and Murray Maloney


Stuart Culshaw, Michael Leventhal, and Murray Maloney


The simplicity of document creation was a key element in the astonishingly rapid development of the Web. This article describes XML and CSS: the "one-two" punch that will not only bring back that level of simplicity, but also enable the construction of complex applications which are either difficult or impossible using HTML. In this article we outline the steps for using an CSS style sheet in an XML document; we discuss the limitations of CSS in complex applications; and we present a real life example.

HTML provides limited possibilities for the explicit formatting and positioning of text. The mechanisms that are provided--such as the FONT element or the ALIGN attribute--force the page designer to embed presentation-specific information within the document; a fact that makes it difficult to prepare documents for a variety of screen sizes, presentation modalities, and types of audiences. Because these limited features are not sufficient to achieve the formatting results desired by many Web designers, they commonly resort to using tables and various HTML coding "tricks." This presents many negative consequences, particularly because it is so difficult to maintain information content in HTML documents; the content is inextricably interwined with the format-related encoding. More sophisticated formatting capabilities have long been needed to support the many document types, ranging from marketing froufrou to legal documents to scientific journals.

Cascading Style Sheets (CSS) is a style sheet mechanism specifically developed to meet the needs of Web designers and users. CSS provides HTML with far greater control over document presentation in a way that is independent of document content. CSS style sheets can be used to set fonts, colors, whitespace, positioning, backgrounds, and many other presentational aspects of a document. It is also possible for several documents to share the same style sheet, which allows users to maintain consistent presentation within a collection of related documents without having to modify each document separately.

The rationale for XML is discussed at length in other papers in this issue; we will thus restrict our introduction to the observation that, in combination, XML and CSS can once again simplify document creation. XML uses markup to describe the structure and data content of a document, making it easy both for authors to write it and for computer programs to process it. CSS, on the other hand, makes it possible to present that document to the user in a browser. CSS or some type of style sheet mechanism is, in fact, a requisite for browsing XML on the Web. If CSS works well with HTML, it will work wonders with XML.

In this article we will illustrate the use of CSS and XML with two examples. We do not describe the syntax of CSS, but refer the reader to the CSS documentation on the W3C Web site.[1]

A Thespian Example

The steps in the following sections illustrate the use of a CSS style sheet for an XML document (an extract from the Shakespeare play "Much Ado about Nothing").

Figure 1

Step 1: The Document Source

Figure 1 shows much_ado.xml; preparing the document source is the first step in using a CSS style sheet for an XML document.

Step 2: Define Style Sheet Rules

The style rules for a document can be stored either within the document itself, or within a separate text file. In this example, we will save the style sheet as a separate file, shaksper.css, so that it can be easily applied to other Shakespeare plays we might like to publish.

You can create the style sheet manually using your favorite text editor, as shown in Example 1.

Alternatively, you can create the style sheet using an editor that supports CSS, such as Grif's Symposia, as shown in Figure 2.

Example 1

PLAY { background-color : white }
FM { font-style : italic;
font-size : 14;
color : #400040;
text-align : right }
SPEAKER { font-weight : bold;
color : #ff0080 }
LINE { color : #800040;
left : 15 }
PERSONA { font-style : italic;
font-size : -1 }
PERSONAE { color : #800040 }
SCNDESCR { margin-top : 30;
font-size : 18;
color : #0000a0;
height : 20 }
STAGEDIR { font-weight : bold;
font-style : italic;
height : 20 }
PLAYSUBT { font-weight : bold;
font-size : 16;
text-decoration : underline;
height : 20 }
SPEECH { margin-top : 5 }

Figure 2

Step 3: Link the Style Sheet
to the Document

At the time of writing, there is not yet a standardized method for linking an XML document with a style sheet. This subject forms part of the work, currently in progress by the W3C, that is due to be published in December 1997 as part III of the XML specification: XML-Style.

The method we will use in this example therefore is based on a draft proposal for stylesheet linking in XML which consists of inserting the XML processing instruction <?XML-stylesheet?> at the top of the document. The processing instruction has two required attributes type and href which respectively specify the type of stylesheet and its address. In our example, we thus need to add the following line to our XML document:

<?XML-stylesheet type="text/css" href="shaksper.css"?> Symposia supports this XML style sheet linking mechanism and inserts the processing instruction for you automatically when you specify an external style sheet using the "Create new Style Sheet/External" command.

Step 4: Publish the Document
and its Style Sheet

Once the style sheet is linked to the document, it can be published. When opened in an XML browser (or in Symposia, as shown in Figure 3), the style rules are applied to the different XML elements in the document.

Figure 3

Limitations of CSS for
Complex Applications

Although CSS style sheets can be very effective for improving the presentation of HTML documents, the CSS1 standard has a number of important omissions which can limit the effectiveness of CSS style sheets for more complex applications. The following list, taken from Jon Bosak's presentation at WWW6 on April 11, 1997[2] describes just a few of the major limitations of the CSS standard:

  • CSS cannot grab an item (such as a chapter title) from one place and use it again in another place (such as a page header).
  • CSS has no concept of sibling relationships. For example, it is impossible to write a CSS stylesheet that will render every other paragraph in bold.
  • CSS is not a programming language; it does not support decision structures and cannot be extended by the stylesheet designer.
  • CSS cannot calculate quantities or store variables. This means, at the very least, that it cannot store commonly used parameters in one location that is easy to update.
  • CSS cannot generate text (page numbers, etc.)
  • CSS uses a simple box-oriented formatting model that works for current Web browsers but will not extend to more advanced applications of the markup, such as multiple column sets.
  • CSS is oriented toward Western languages and assumes a horizontal writing direction.
It is for these reasons that the W3C working group responsible for the XML standard is concentrating its efforts on the implementation of a simplified version of the DSSSL standard, DSSSL Online (DSSSL-O). DSSSL-O promises to provide far more layout and document presentation features than CSS, but is a considerably more complex standard and may prove difficult to implement.

What is clear, however, is that the limitations of CSS1 do represent a serious hinderance for its use in the more complex types of application that are possible with XML. As the following section shows, even for a somewhat simple XML application, the CSS standard needs to acquire a certain number of essential features if it is realize its full potential.

A Real Life Example

The following example is taken from a Marketing Contact application which is actually in use at Grif. The Marketing Contact application allows our staff to record information and update information about our business contacts, and to extract reports and find existing records based on specific criteria using a search engine. Though this type of application is often implemented using a database such as Access, a more Web-centric approach would be to create an interface to a database using HTML forms. We choose instead to simply create our database records directly using Symposia. Our search engine is XML-capable so the equivalent of field-specific searches can be performed within XML elements. Among the advantages of this approach is that our application is entirely Intranet-based; and as a result we were neither required to write a line of CGI code, nor to develop HTML or database forms.

The DTD for our application is shown in Example 2.

Example 2

          <!XML version="1.0">
          <!DocType ContactRec [
          <!Element ContactRec (Name, Company, Address, 
          Product, Contacts)>
          <!Element Name (Honorific?, First,
          Middle?, Last)>
          <!Element Company (JobTitle?, CompanyName)>
          <!Element Address (Street+, City, Region?,
          PostCode, Country, Phone,
          <!Element Product  Empty>
          <!AttList Product
          SGMLEditor (Yes|No) #REQUIRED
          SGMLEditorKorean (Yes|No) #REQUIRED
          SGMLEditorJapanese (Yes|No) #REQUIRED
          ActiveViews (Yes|No) #REQUIRED
          SymposiaPro (Yes|No) #REQUIRED
          SymposiaDocPlus (Yes|No) #REQUIRED
          XMLProducts (Yes|No) #REQUIRED
          General (Yes|No) #REQUIRED>
          <!Element Contacts (Language, History)>
          <!Element Honorific (#PCDATA)>
          <!AttList Honorific
          Title (Mr|Ms|Mrs|Miss|Dr|Professor|M|Mme|Mlle|SeeContent) "SeeContent">
          <!Element First (#PCDATA)>
          <!Element Middle (#PCDATA)>
          <!Element Last (#PCDATA)>
          <!Element JobTitle (#PCDATA)>
          <!Element CompanyName (#PCDATA)>
          <!Element Street (#PCDATA)>
          <!Element City (#PCDATA)>
          <!Element Region (#PCDATA)>
          <!Element PostCode (#PCDATA)>
          <!Element Country (#PCDATA)>
          <!Element Phone (DayTime, Fax?)>
          <!Element Internet (Email, Web)>
          <!Element Language  EMPTY>
          <!AttList Language
          Preference (English|French) "English">
          <!Element History (Events+)>
          <!Element DayTime (#PCDATA)>
          <!Element Fax (#PCDATA)>
          <!Element Email (#PCDATA)>
          <!Element Web (#PCDATA)>
          <!Element Events (Date, Venue, Notes)>
          <!Element Date (Day, Month, Year)>
          <!Element Venue (#PCDATA)>
          <!Element Notes (#PCDATA)>
          <!Element Day (#PCDATA)>
          <!Element Month (#PCDATA)>
          <!Element Year (#PCDATA)>

A form-based interface provides many user-friendly features that make data-entry easier for the user, such as the ability to select from a predetermined list of options, or the possibility to select or unselect different options, as appropriate.

To provide an equivalent level of "comfort," we need to provide a predefined document template in which the user need only fill in the required data. Using the DTD as our guide, we can produce a document instance that contains all required document elements. Without a style sheet, however, this template is not of great value. The editor will simply display the document as a list of tags. Users need to know what information to insert where without displaying these tags--the only way we can accomplish this is by using our style sheet.

With the HTML form, it was possible to simply label each input zone with some text. Unfortunately, the CSS standard does not provide a means of displaying predefined text before or after an element. This style sheet feature was left out of CSS1 because of the inherent difficulty of implementing this feature in today's Web browsers (which, of course, by the time you read these words, will already be yesterday's Web browsers). Structure based editor/browsers such as Symposia, or indeed the thoroughbred XML structured editors to come, would have no problem implementing this type of feature, if it were included in the CSS standard.

The only viable solution for the moment seems to be to provide default text content for each data field that is then replaced by the user as he/she enters the information in the page (see Figure 4).

Figure 4

This layout is still not very satisfactory, however. Figure 5 improves the layout of the page using our style sheet to highlight certain elements and group related items together.

While we can achieve quite a pleasing presentation for our data entry screen using the style sheet. However there are two elements in the DTD which we cannot display in this same way: Product and Language. These two elements are empty and have no text content.

  • The Product element takes a number of optional attributes to indicate the contact's interest in the company's different products (the value of each attribute is "Yes" or "No," accordingly.
  • The Language element takes the Preference attribute, which can take the values "English" or "French," and for which the default value is "English"--indicating that any communication with or documentation sent to the contact should be in English.

One way around this problem, although not very elegant, would be to specify a background image for each element using the following style rule:

 Product {background-image:image.gif} 

Using our authoring tool, we would then be able to select the element by clicking on the image and pull up a list of the element's attributes for modification, as shown in Figure 6.

Figure 5

Figure 6

Of course, we are still left with the following problem: using CSS, it is not possible to display the attribute names or values for an element in the document itself. In our example, it would have been nice to be able to pull up the list of attributes for the Product element, supply a value for each attribute, then see these changes appear in the document (display some text or an image to indicate which products the contact was interested in, for example). Neither does CSS provide the possibility to apply conditional style rules based on an element's attribute values (one might imagine a different image to be displayed for "Yes" or for "No" values).

Despite the limitations of CSS described here we have found that the language comes close to meeting our needs. This, combined with the fact that CSS is already implemented for HTML in the major Web browsers--and our sense that the simplicity of CSS will appeal to Web designers over more complex (albeit powerful) approaches--leads us to believe that CSS will be the dominant mechanism for displaying XML documents on the Web.

About the Authors

Stuart Culshaw
Technical Communication Manager
Grif S.A.,
BP 266,
78053 St Quentin en Yvelines Cedex,
Stuart Culshaw is Technical Communication Manager at Grif S.A., a leading SGML and XML software development company. He manages the production of both printed and Web-based documentation for Grif's products and is charged with investigating and evaluating emerging Web technologies and standards.

Born in Morecambe, England in 1970, Stuart joined Grif in 1993 after completing a Bachelor's degree course in European Business Studies. He also holds a Certificate in Technical Writing from the American University of Paris.

Michael Leventhal
Grif, S.A.
Vice-President, Technology
1800 Lake Shore Avenue
Suite 14
Oakland, California 94606
Michael Leventhal is Vice-President, Technology for GRIF and is responsible for the definition and planning of GRIF's XML products. Before joining GRIF he ran his own consulting company and has worked for Oracle and other Silicon Valley firms in software architecture and development. He has taught an SGML class for U.C. Berkeley Extension and is writing a book on XML and Intranets which will be published by Prentice-Hall next year.

Murray Maloney
Technical Marketing Director
Grif S.A.
671 Cowan Circle
Pickering, Ontario
Canada L1W 3K6
Murray Maloney represents GRIF S.A. as their Technical Marketing Director. A leader in the development of Web standards since 1993, Murray is a founding member of the HTML, XML and CSS working groups, and participates in numerous others. He was previously a technical director with SoftQuad and publishing systems architect and manager with the Santa Cruz Operation (SCO). Murray is a technical advisor to the Yuri Rubinsky Insight Foundation, co-chair of the 8th International World Wide Web Conference to be held in Toronto in 1999. He produced the index to Charles F. Goldfarb's SGML Handbook and is co-author, with Yuri Rubinsky, of the recent SGML on the Web: Small Steps Beyond HTML.

[1] See For a user's guide to CSS syntax also see the article by Norman Walsh in the Winter 1997 issue of W3J, Advancing HTML.
[2] "Overview: XML, HTML, and all that." See also Jon Bosak's article in this issue entitled "XML, Java, and the Future of the Web."