Table of topic groups > Front page of CSS-guide > Proposals > CSST

Cascading Style Sheets with Transformation (CSST)

Topics

• Status of this document
• Transformation rule
• Advances of my proposal
• Criticism towards XSL-fo

Status of this document

This is an an-official proposal to put XSLT and CSS together. Besides XSLT there is element- and attribute-based layout/styling and transformation languages XSL-fo. The basic idea according to one of the designers of XSL-fo is, that XSL-fo is a unified approach where all the formatting description is attached wi1px one framework rather than some in the semantics of HTML and others outside of that framework.

I don't like however the way, how XLST + XSL-fo create this. The structure is reasonable to write with HTML resemble semantics. But HTML resemble semantics is extremely heavy and stiff in describing layout/styling. I like more CSS-style script-based formatting language.

I have never liked HTML 3.2, because in HTML 3.2 the structure and layout are both described with elements and attributes and it is a unified approach. I love the basic idea, to describe layout/styling outside HTML framework in short and compact scripts.

XSL-fo means for me returning back to the unified HTML 3.2 style heavy and stiff approach, which I have never liked. XSL-fo might be good language for people, who have never used CSS and are experienced users of HTML 3.2. But all people don't like this designing principle. That's why I hope, that I could in future write all the same with XSLT + CSS3. If XSLT + XSL-fo will be dominant, I is really a loss for people like me.

Let's make some examples. XSL-fo means these kinds of elements and attributes:

<xsl:template match='header1'>
<fo:block space-before='6pt'
space-after='6pt'
text-align='justified'
font-size='21pt'>
<xsl:apply-templates/>
</fo:block>
</xsl:template>
<xsl:template match='header2'>
<fo:block space-before='6pt'
space-after='6pt'
text-align='justified'
font-size='18pt'>
<xsl:apply-templates/>
</fo:block>
</xsl:template>

If there is a need of tree transformation, there is need also:

<xsl:template match="header2">
<h2>
<xsl:template match="header2">
<h2>
<xsl:apply-templates />
</h2>
</xsl:template>
<xsl:apply-templates />
</h2>
</xsl:template>

XSLT + CSS needs the tree transformation, but the layout/styling could be expressed with more compact way in an external CSS file like this:.

h1,h2 {text-align:justify; space-after:6pt;space-before:6pt} /* all in the same statement; all properties in XSL-fo are not supported in CSS2, but they could be implemented into CSS3 */
hi {font-size:21pt}
h2{font-size:18pt}

In CSS it is possible to make rule groups and declaration-blocks, which are easy to write and edit. They need less code than XSLT + XSL-fo.

In theory it is possible to make own XSL-fo files to several media groups, but it is much work to do so. It is much easier to tailor style sheets do different media with CSS.

Transformation rule

Today creating tree transformations, it is necessary to use XSLT, but why not to make transformation implementation into CSS. Script-based CSST could be much more compact than XSLT. Let's make an example. The proposal base on that instead of element-based stiff and heavy XLST, CSST could use the transform rule like this:

@transform {} screen; /* the transformation rule could need always the media type and it should be after all import rules on the top of the style sheets before any media or other rules */

The main matter is to discuss how to express XSLT source and result tree transformation with rules, which fits well to the CSS common semantics. At least it could be much more compact to use scripting to describe the source and result treen than by using actual elements in xls-templates (heavy to write and stiff to edit). Lets make element type names to represent source and result tree markup tags. One possible solution might be like this:

@transform {header1 = h1; /* the basic idea is the same as in JavaScript; These are adapting statements; On the right is source tree elements and on the right result tree elements */
header1 = h1/b; /* / marks represent nesting levels in the document tree */
header1 = h1;
header2 = h2/i;
calculation-box = table/tr;
calculation = td[@class="calculation"];
item = li} screen;

These kind of short scripts are easy to edit. By using :before and :after pseudo-elements, it is possible to add small text fragments before or after element. Inside brackets could be added some attributes. If source tree is described with location paths and not actual source elements, I can't understand, why result tree must describe with actual element and not just location paths. In my mind both source and result tree can be desrcibed only with location paths and patterns.

XSLT has sorting system. Instead of elements and attributes, sorting could be described with scripts by using new rules, new properties and new values like this:

ol li {sort:ascending} /* instead of XSLT xsl:sort could be used new properties or pseudo-classes*/

Xsl:when and xsl:if could be easily described with JavaScript style short scripts instead of elements like in the BECSS proposal. Again elements are stiff and heavy to use, but not so much as in XLS-fo. In my mind elements are reasonable only in the main HTML or XML documents. They make easy to shape the contents. Styling/layout language should be easier to use as XSL-fo. Also structure language could be easier to write and edit as XSLT.

Advances of my proposal

CSST could be much more lighter system than XSLT + XSL-fo. There is already CSS2 and XSLT recommendations and XSL-fo working draft as the model to design CSST.

If this can't be solved with author-side languages, I would like that someone could create server-side application or develop existing applications to make with easy and short encoding (like java-scripts) the same as XSLT. By using serve-side application XSLT replacing system could be used also with ordinary HTML-documents. Then missing CSS-properties doesn't make any problems. CSS could be needed just for presentation (not creating basic element behaviors with display-properties like display:table-cell).

Criticism towards XSL-fo

XSLT and XSL-fo base on old XSL proposal. XSL-fo has much common to 1997 proposal. Microsoft made one an application, to convert XSL + XML to HTML + CSS documents (in that proposal XSL attributes were converted into individual style sheets inside style attributes (style="...")).

That proposal don't break net into XML and HTML. XSL-fo is independent formatting language, which have its own attributes and properties. Because it is only partially but not totally developed together with CSS, it disperse the Internet into small pieces. If XSL-fo could be developed together with CSS3, they could share same properties. Then XSL-fo could convert easily into XHTML + CSS. But according to the existing working draft and proposals to CSS3, this is not possible (or some properties are lost in converting into CSS). It seems that there is more competition than co-operation developing XSL-fo and CSS3. This is extremely bad matter.

Even if I don't like very much XSLT, I can accept it. But I don't keep XSL-fo reasonable and resist it. We should think carefully following critical writings.

I got some comments to them from a writer of the W3C XSL working draft document, which handle XLS-fo. XSL-fo has altered after their comments:

They have found the inclusion of a 'source-document' property on fo:root (to point back to the source XML/XHTML document) and a 'role' property on all xsl-fo nodes (to provide aural readers with a source semantic) to be a sufficient answer to their needs. This answers the additional issues raised by David Baron.

This might solve the semantics problems, but XSL-fo is heavy anyway. The code could be be shorter at following way:

1. Source and result tree patterns could be combined inside single match-attributes.
2. Individual properties could be combined inside single style-attributes like in CSS.