XML and CSS
October 2, 1997
Stuart Culshaw, Michael Leventhal, and Murray Maloney
XML and CSS
Stuart Culshaw, Michael Leventhal, and Murray Maloney
Abstract
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.
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,
Internet)>
<!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,
- FRANCE
- Stuart.Culshaw@grif.fr
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@grif.fr
- Murray Maloney
- Technical Marketing Director
- Grif S.A.
- 671 Cowan Circle
- Pickering, Ontario
- Canada L1W 3K6
- murry@grif.fr
[1] See http://www.w3.org. 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."