XSL and CSS: One Year Later

Last year, a hot topic in the XML community was the Extensible Stylesheet
Language (XSL)--specifically, the aspects relating to text layout, so-called Formatting
Objects (XSL-FO). Just over a year later, and the debate about
XSL-FO, and its relationship with CSS, has cropped up again. This week
XML-Deviant digs into the discussion to see if any new issues are
being raised.

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.

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

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.

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.

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.

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.

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.

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.