XSL and "No Fault" CSS

by Richard G. Baldwin
baldwin@austin.cc.tx.us
Baldwin's Home Page

Dateline: 05/30/99

what? no SAX!

Last week I promised you that I would continue the discussion of SAX in this week's article. However, in the meantime, I've been reading about the controversy surrounding XSL and CSS. I decided to gain a little first-hand experience in that area. I'll get back to SAX in a later article.

the controversy

The controversy involves Michael Leventhal of the "zilla" product developers on one side who believes very strongly that the effort being expended on XSL is wasted effort and "has set the web back at least two years." He believes that the combination of XML, the Document Object Model (DOM), and CSS can do anything that is promised by the proponents of XSL.

The proponents of XSL include G. Ken Holman who has written a very interesting article in favor of XSL.

Whichever side of the controversy you come down on, this makes for some very interesting reading.

the Lotus XSL Processor

In my efforts to gain some first-hand experience, I first went to the IBM alphaWorks site where I downloaded and then installed the Lotus XSL Processor. After installing the software, I tried unsuccessfully to run the acceptance tests to confirm a successful installation. I kept getting an error message to the effect that a particular file couldn't be found. I didn't have much time to troubleshoot the problem, so I never did figure out what was wrong.

XSL demos were interesting

Even though I was unable to run the acceptance tests, I was able to run some of the demonstrations included in the Lotus XSL download package. The results were pretty interesting.

a real-estate demo

There is one especially interesting demonstration that simulates a real estate site. This demonstration provides two panels. A grid of properties being offered for sale is displayed in one panel. Clicking one of the properties in that panel causes a picture of the property to appear in the other panel.

raw data is stored in XML files

The raw data for the demonstrations is stored in XML files. The demonstration uses an XSL file to transform an XML file into an HTML file. The demonstrations allow you to view the raw XML data, the XSL file, and the resulting HTML file.

XSL seems complicated

I haven't done anything with XSL before, and my initial reaction was that the XSL file looks pretty complicated. However, so did HTML the first time I saw it several years ago. A little study of XSL would probably cause the complexity to melt away pretty quickly.

XSL seems slow

Another observation was that the transformation of the XML files into the HTML files required an awfully long time on my 133 MHz Pentium machine. This seems to confirm one of Leventhal's arguments against XSL. He argues that CSS, when combined with DOM already provides everything that can be done using XSL, and can do it more quickly.

However, the documentation for the Lotus XSL demos pointed out that the software has not yet been optimized for speed, so I suppose that we shouldn't expect too much in the way of speed at this point.

the Lotus XSL Processor is worth a visit

In any event, it would definitely be worth your while to visit the IBM alphaWorks site, download the software, and run the demonstrations for yourself. The download package isn't very large so it doesn't take a long time to download and install it.

It does require some knowledge of the Java classpath environment variable. If Java is new to you, take a look at my online Java tutorials.

using CSS

After experimenting with the Lotus XSL Processor, I took a look at CSS. I have never used stylesheets on any of my web pages before. My reasons have been much the same as the reasons outlined by Zeldman and Platz in their article entitled "Fear of Style Sheets."

using No-Fault CSS

To take away some of that fear, they describe what they refer to as "No-Fault CSS." What they mean by this is using CSS in such a way as to enjoy some of the advantages of CSS while still remaining compatible with most of the existing browsers.

decided to give it a try

I decided to give CSS a try and publish an article using their No-Fault CSS on an experimental basis. I also used information gleaned from Dr. Web and the article entitled "Div"ersity by Aaron Meyers.

I found stylesheets to be very intuitive

Although I found stylesheets to be very intuitive once I saw some examples, I did need some help in getting started to create my own stylesheet. The help came mainly in the form of sample code, which prevented the need for me to have to figure it out for myself.

testing my CSS implementation

I tested my HTML file with a stylesheet using Communicator 4.5 and Internet Explorer 3.0.

Supposedly Internet Explorer 5.0 is CSS compliant while the two that I used are not totally compliant. However, I didn't have the patience to download MSIE 5 solely for testing my CSS implementation, so I don't know how it behaves.

The results didn't look quite the same for the two browsers that I used for testing, but the results seem to be acceptable for both.

compatibility problems with Word 97

I did encounter major problems with stylesheets and the Word 97 program that I use for WYSIWYG generation of my web pages. I tried to get fancy and create some custom tags using the HTML DIV directive.

Word got in the way

Word 97 refused to leave my STYLE script and custom tags alone. It insisted on corrupting them each time I edited the HTML file. I finally ended up eliminating custom tags and using the stylesheet solely for controlling the appearance of standard tags such as <P>, <H3>, and <H4>.

Of course, I could use custom tags along with the HTML DIV directive if I were willing to do all of my HTML editing using a different editor (possibly a non-WYSIWYG editor). However, I don't have the patience for that.

the stylesheet is very useful

Even without custom tags, I found the stylesheet to be very useful in keeping me on speaking terms with Word 97. Normally when I use an overall font that is different from the default font, my Word 97 editor causes all sorts of problems. The problems result in the default font showing up in some portions of the document (such as links) and the other font showing up in other portions of the document. Then I end up having to do a cleanup edit using a non-WYSIWYG editor.

With a stylesheet, I can edit the document as though I am using the default font, which makes my Word 97 editor happy. Then I can cause it to be rendered in a different font simply by specifying a different font in the stylesheet.

I like it!

I may start using No-Fault stylesheets routinely when I want to use something other than the default font.

the STYLE script

CSS is implemented by putting a <STYLE TYPE="text/css"> ... </STYLE> element in the header portion of the HTML file enclosing the script that defines the desired style. (It is also possible to reference a file containing the script, which makes it possible for many HTML files to share a single script.) You can easily view the script for this document by viewing the raw HTML in your browser.

I won't attempt to explain the script to you. Rather, I will refer you to the links provided earlier for information on how to implement CSS in an HTML page.

If you find any major problems with this page and your browser, I would like to hear about them. Please be sure to include information on the browser that you are using when the problems occur.

so, what does this have to do with XML?

In an earlier article, I told you that a useful XML document has three parts. One part is the material that you wish to expose to the reader. The second part is an optional DTD.

The third part, and this is where either XSL or CSS comes into play, is a mechanism for rendering the XML document in a prescribed manner.

rendering instructions

There are several possible ways to implement the rendering mechanism. For example, in a Java application or applet, you could use the facilities of either the AWT or Swing to produce the desired rendering.

converting processed XML to HTML

Another obvious way to implement the rendering mechanism is to convert the processed XML document into an HTML file and serve it to a browser. Including either XSL or CSS in that conversion process has a lot of promise.

consider a Java servlet

For example, consider a Java servlet that is invoked by a browser to process XML data and display the results. The purpose of the servlet is to

assuming that the browser supports stylesheets...

The code required to generate the HTML files could be made much simpler by incorporating (or referencing) a stylesheet rather than including a lot of formatting information in the HTML that is generated.

In addition, the resulting HTML file could be much smaller. For example, this document contains only one <FONT> tag, and it is used to produce the white text on the red background that you see below. (Since that occurs only once, I elected not to include it in the stylesheet.) If this document didn't use a stylesheet, it would contain dozens of tags of the <FONT FACE = ...> variety. This would increase the total size of the document and increase the download time accordingly.

coming attractions...

My plan for the next article is to resume the discussion of SAX-based parsers, and to introduce you to a software product from IBM named XML for Java. This product supports both SAX and DOM, and lets the application programmer combine the two approaches in a single application. You can download this parser from IBM free of charge.

As I have mentioned before, trying to get your arms around XML is sort of like trying to put an octopus in a bottle. Every time you think you have it under control, a new tentacle shows up. XML has many tentacles, reaching out in all directions. But, that's what makes it fun. As your XML host, I will do my best to lead you to the information that you need to keep the XML octopus under control.

Credits -- This HTML page was produced using the WYSIWYG features of Microsoft Word 97. The images on this page were used with permission from the Microsoft Word 97 Clipart Gallery.

310913

Copyright 2000, Richard G. Baldwin

About the author

Richard Baldwin is a college professor and private consultant whose primary focus is a combination of Java and XML. In addition to the many platform-independent benefits of Java applications, he believes that a combination of Java and XML will become the primary driving force in the delivery of structured information on the Web.

Richard has participated in numerous consulting projects involving Java, XML, or a combination of the two.  He frequently provides onsite Java and/or XML training at the high-tech companies located in and around Austin, Texas.  He is the author of Baldwin's Java Programming Tutorials, which has gained a worldwide following among experienced and aspiring Java programmers. He has also published articles on Java Programming in Java Pro magazine.

Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.

baldwin@austin.cc.tx.us
Baldwin's Home Page

-end-