XSL and CSS: One Year Later

Some Background

The original XSL specification defined transformation and styling components. However, the transformation aspects of the specification were later factored out, giving rise to XSLT and XPath. Both of these became W3C Recommendations last December, while the styling component of XSL, formatting objects, is still under slow development.

Last year's XSL debate centered largely on the lack of semantic information inherent in FOs. The definitive source of this critique was Håkon Lie's article "Formatting Objects Considered Harmful." In this paper, Lie describes XSL-FO as having no more semantics than a document consisting solely of <font> tags. The fear is that if FOs came to replace HTML as a presentation language, then the "semantic web" would be much harder to implement.

XML.com provided coverage of both sides of the debate, publishing firstly an article by Ken Holman ("What's the Big Deal with XSL?"), followed by a "declaration of war" from Michael Leventhal ("XSL Considered Harmful"). Holman praised XSL, particularly the ability to transform data into new XML formats. Leventhal was strongly against XSL, believing it to be too complex, and less capable than CSS for styling web documents.

This points to another aspect of the debate, namely the relationship of XSL to CSS. Both are styling languages and products of the W3C Style Activity. The confusion prompted the W3C to eventually issue a Note on using XSL and CSS together. Bert Bos, leader of the W3C Style Activity has also attempted to address the question of why the W3C is producing two style languages, including posting a public statement on the W3C Style mailing list regarding the relationship between XSL-FO and CSS:

I think the relationship between XSL(FO) and CSS is best expressed by their respective goals. If we leave XSLT apart for the moment (since it can be used with CSS as well as with XSL Formatting Objects), then CSS is the 80% solution, XSL(FO) the high-end tool for the next 15%. The remaining 5% needs real programming.

On the scale between capabilities, usability, and ease of implementation, CSS stresses usability, then implementation, and is willing to limit its powers. XSL is the reverse. In other words: CSS should be accessible to everybody, XSL should be able to do almost anything.

The Problems With XSL

So what are the issues being discussed today? Thierry Hanser prompted the discussion by looking for a way to render XML documents to paged media:

As I am not expert in page-media publishing, I am not able to evaluate the current power of FO and its fitness with the wide field of paper-like publishing. It seems to me that the FO specifications are pretty well designed (at last a humanly readable rendering model) and quite comprehensive but I might be wrong.

Therefore I would be happy to read your own feelings about the quality, [caveats] and future of the Formatting Object model.

Urging caution until the specification is complete and tool support is available, Sebastian Rahtz expressed concerns about the heritage of XSL-FO:

What worries me is that XSL FO's parents are DSSSL and CSS. Not a very healthy start. DSSSL was never accepted by any major player, or implemented to the extent one could do top-quality typesetting with it; and CSS, well what can one say... Not exactly unimplemented, but implemented so badly and so incompletely it leaves a nasty taste in the mouth.

Rahtz is referring to the lack of consistent CSS support in the major browsers, and the debt the design of XSL owes to DSSSL. Interestingly, DSSSL itself was an attempt to build a styling language aimed at improving on FOSI, a much earlier attempt to build an abstract model for document styling and formatting.

Whilst more positive about the specification, Rick Jelliffe believed that tweaking of the results would be necessary:

I am excited to see the results of XSL-FO: it is looking great. But a good page design will often need to be tuned to fit the formatter.

Marcus Carr observed that formatter-specific tuning lessens the usefulness of XSL-FO:

Even using two different applications to render an FO document, you likely wouldn't get the same result, so you're still going to end up choosing one application or the other. This completely negates the gains made by the abstracted format - you may as well just choose the application up front and work with it's particular formatting interface.

Is XSL-FO on Target?

It quickly became clear that the usefulness of XSL-FO depended on the context in which it is likely to be used. As Thomas Passin commented, there is no clear consensus on what those target applications are:

It seems that we're not sure of the intended use of FOs - high quality, low volume, or high volume, lower quality. Could one system do both well???

The statement made by Bert Bos last year is less clear-cut given the continuing development of CSS. CSS and XSL are approaching each other from opposite ends of the spectrum: CSS favors simplicity and is adding functionality; XSL the reverse. For example, CSS includes pagination features and also properties to support aural formatting.

Ashvil thought that XSL-FO would become an open file-format:

My personal view of xsl:fo is a Open XML file format that is an alternative to PDF, similar to SVG being an alternative to Illustrator, Flash, [and] other vector graphics format[s].

Taking the alternate view, Rick Jelliffe believed XSL-FO would instead contribute to improving the design of formatting applications:

I am not sure that XSL-FO really is best thought of as an interchange language. I would see it far more as an internal interface within an XML-based typesetting system which provides a convenient way to specify a formatter as a black box.

These viewpoints summarize the important sources of debate. The lack of semantic information in an XSL document is a critical failing if Formatting Objects are expected to replace HTML (this is the area that saw most coverage last year). If XSL-FO is intended as an all-encompassing document formatting language, then the debate centers on its expressive power. James Robertson wondered whether there was additional information available to inform the debate:

I presume that during the development process for XSL-FO, a comprehensive review was made of current tools and technologies...

If this process was followed (surely it was), can we have the list? This would provide us with the best comparison of XSL-FO and other systems.

Sebastian Rahtz observed that clarifying the intended purpose of XSL-FO may curb the XSL vs CSS debate:

Many people seem to regard XSL FO as covering more or less the same area as CSS; for myself, I want high-end typesetting, and am "happy" to use HTML+CSS on the Web, but I suspect I am unusual.

However there are some unreconcilable differences between the alternatives: XSL involves transformation, CSS annotation.

Jon Smirl, a contributor to the development of FOP (an open source XSL-FO to PDF formatter), thought that XSL-FO should not remain "pigeon-holed" as a print formatter, believing instead that it should be integrated into the browser:

Personally I'd like to see SVG ==> XSL-FO =optionally=> HTML/CSS become the unified rendering/DOM/event standard from the W3C. This would allow a core browser to be developed that could easily be ported by reimplementing the SVG layer. From this same core it would be easy to implement PDF output also. A unified XML model at all layers would be a major blessing.

Working Towards a Resolution

There are two ways to help resolve the debate. A start would be for the W3C to update their design documents to better inform developers of their goals. The second, and perhaps the only way to confirm that XSL-FO will meet its requirements, is to implement additional FO-aware applications. This will involve significant commitment from the developer community.

Peter Murray-Rust has been quick to encourage the FOP developers, drawing comparisons with early work on SVG:

To give heart to those involved - SVG made it spectacularly. Look back through the archives - even two years ago and you will see gloom about every coming out with a communal spec for vector graphics. We now have many high quality implementations. 2-D graphics is also non-trivial - I have spent many years in that area - and I think SVG is a top class spec. I can see no reason why XSL-FO cannot follow in this tradition - the principles are known and the value should be clear.

Murray-Rust saw the style activity as an essential component towards achieving the vision of XML. Didier Martin pointed out that usage of XSL-FO will be reliant on wide-spread tool support and the network effect this causes:

...the incentive to learn and use is mostly driven by the browser and authoring tools manufacturers. Or actually, it is also in the hand of people with a lot of free time and who are willing to design/code for no fees. If the "gizmo" language is included in all browsers and all authoring tools, then this "gizmo" language is interesting for the people. This is the network effect...

...What is needed though is a fast [XSL-FO] to HTML translation tool in addition to [XSL-FO] to PDF that we have today. Someone ready to take the torch? Also ready to make it work and give it Mozilla?

The publishing industry is embracing the Internet, and is beginning to look for ways to easily re-purpose their content to support new ventures like the "e-book" and Print On Demand (POD). There is obviously a clear requirement for a suitable formatting language capable of supporting these kinds of systems. The industry had a significant presence at XML Europe 2000, and is already producing vertical standards such as PPML, and expressing their own concerns about the capabilities of XSL to support their needs. It would be a shame if XSL-FO failed to meet its promise.