Re: http://www.nic.fi/~tapio1/Teaching/CSST.html

At 14:58 2000-02-05 +0200, Tapio Markula wrote:

[SDeach] I have taken Tapio's web posting and converted it to text so I
could respond via basic e-mail. His text appears in line preceded with the
">" marker. (Some indention was lost in this extraction.)

>Topics
>
>  -- The status of this document 
>  -- Transformation rule 
>  -- Advances of my proposal 
>  -- Criticism towards XSL-fo 
>  -- A list of proposals (in another page)
> 
>
>THE 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 within one framework rather than some in the
>semantics of HTML and others outside of that framework.

This was, in fact, a requirement presented to the XSL-WG (not a goal). This
is due to the fact that XSL must support XML and XHTML input documents,
thus must be able to assign presentation semantics to either input format.

Similarly, it was a requirement that XSL be a pure XML syntax.

Third, at the request of the CSS and w3C staff representatives to the
XSL-WG, it was decided that XSL-FO should NOT use any existing HTML tags,
due to the confusion it would cause between content semantics and
presentation semantics.

Fourth, you want to bring CSS & XSL together. So do we. The CSS, XSL, and
INTERNATIONALIZATION working groups have spent several years working
together to normalize a common formatting model and property set, to allow
for cooperative interaction between the diverse requirements of the working
groups and a broader range of customers/clients than any individual group
was initially addressing. The XSL (FO) draft is the largest outcome of that
effort.
  As is the case with many large problems, a single solution is not always
possible nor desireable. A coordinated multi-layered solution is often
required. There are problems where a CSS approach to formatting is best and
problems where an XSL-FO approach to formatting is best. The goal has been
to allow the user to make a choice for a given solution, with sufficient
compatibility between approaches that conversion to an alternate approach
is possible.

>
>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.

XSL-FO is not meant to replace an XML or HTML document, it is a language
for expressing the desired styling & layout to be applied to an XML/XHTML
document, in an unambiguous manner such that it is possible to build a
formatter in a cost-effective manner that can produce a broader range of
documents than can be described using today's W3C recommendations.

>
>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>

What are you trying to show here? You seem to have jumbled h1's and h2's
with respect to the XSL example.

I assume you intended:
  <xsl:template match='header1'>
    <h1>
      <xsl:apply-templates/>
    </h1>
  </xsl:template>
  <xsl:template match='header2'>
    <h2>
      <xsl:apply-templates/>
    </h2>
  </xsl:template>

But you need to include the styling, so you need to add:
  h1,h2{text-align:justified;
        space-after:6pt;
        space-before:6pt}
  h1{font-size:21pt}
  h2{font-size:18pt}

And then you have only saved yourself about 3 lines (and a few quotes) for
the total property specification (the repeated text-align, space-before,
and space-after values), plus the shorter element names (but you have added
back the selectors h1,h2{} and h1{} and h2{}, so you haven't saved all that
much -- and it gets slightly worse if the selectors are context-dependent).
               
>
>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.

  These optimizations (combining the specification for several properties
in the  "h1,h2:{...}" rule, then overriding/extending individual properties
in a separate "h1:{...}" and/or "h2:{...}" rule) only work in simple
formatting examples where the style sheets are hand-edited and hand-optimized.
  Again, it was decided not to allow "partial" specifications of
non-inherited properties to be indirectly assigned to XSL-FO in XSLT
(cascading), since this is a cause of a large number of styling errors and
a large number of bugs in the transformation/style-assignment script. (How
likely would it be that you would find a the bug and how long will it take
to find, had you specified: "h1{font-size:21pt} h1{font-size:18pt}" instead
of "h1{font-size:21pt} h2{font-size:18pt}").
  The implementors of formatters have demanded that the property assignment
processing be done in XSLT and not in the formatter. (Inconsistencies in
the resolution of conflicting cascade rules is one of the causes for
differences in the quality of CSS-2 implementations.)

>
>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.

In theory, it is possible to make a single CSS stylesheet that supports
multiple media groups, I reality, the use of a single stylesheet/script to
map to multiple media only works for the most trivial documents. It
produced poorly styled documents as soon as one has multi-article documents
and/or documents with requirements beyond the most-basic WP-style pagination.
  Over 30 years of personal experience in a broad spectrum of document
production systems has shown that as soon as one has a slightly more
complex document it is impossible (without document-by-document and
presentation-by-presentation hand tuning) to map the
presentation-properties/formatting-events into the content-structure, and
it becomes necessary to map the document onto a special set of presentation
objects with thier own hierarchy.
  As soon as one attempts to create quality presentations on different
media, a multi-media stylesheet becomes extremely complex and most of the
optimizations the CSS provides become useless.
  In discussions that I and other members of the XSL-WG have had at various
conferences over the past 2 years with many document and stylesheet
designers for companies (and agencies) with significant (in-house or
client) cross-media requirements, it turns out that most designers would
prefer to do media-specific designs that can be tailored to the display
capabilities, animation or full-motion video capabilities, audio/aural
capabilities, traversal mechanisms, and the "feel" of a specific media;
even if this involves writing several stylesheets. When asked if @media
controls in CSS were adequate, most designers said no. (I notice that your
pages have major differences for frame and non-frame environments, as well
as design differences in the Finnish pages and the English pages. I suspect
you don't always share common stylesheets across all languages and
browsers. If you do share them, the differences are also quite difficult to
cover in a single stylesheet.)
  It has been determined that about 1/2 the document categories in my
previous response can not be represented in CSS and that CSS has
architectural limitations that will prevent adding them. The lack of a
styling and layout language that can support them is keeping a vast library
of documents off the web. (It should be noted that this is not just due to
a desire for artistic control, but is often mandated by law or required by
common/current business practice and/or mandates of professional bodies.)
If it was a straightforward as you suggest, I (and some 20-30 other people)
would have avoided nearly 3 years of work to produce the XSL-FO standard
and would have suggested extensions to CSS to satisfy these needs.


>
>
>TRANSFORMATION RULE

I will not debate the merits vs. detriments of XSLT, it has already been
accepted as a W3C recommendation.

>
>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 (hard 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.
>
>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 hard 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.
>
>
>CRITICISM TOWARDS XSL-FO
>
>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:
>
>Formatting Objects considered harmful (Håkon W Lie) 
>Re: CSS vs XSL, what is going on (L. David Baron) 

These documents are approximately 1 to 2 years old, and the issues they
raised have been formally addressed through coordination efforts with
appropriate W3C working groups and with W3C member companies/organizations
that develop/utilize products/specifications in these domains and through
public comment mechanisms on several forums.
  The XSL-WG's responses to Håkon's paper have been presented in the forum
where Hakon's paper was published and in a number of other public-comment
forums and the majority of the comments found our responses acceptable and
or preferable to his proposals.
  We have held a number of meetings with representatives of the W3C WAI
group and with manufacturers and consumers of WAI tools. 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 thier needs. This answers the additional issues raised by David Baron.

>
>------------------------------------------------------
>Tapio Markula
>Expert on
> __
>¦__¦__ Cascading 
>¦__¦__¦__ Style
>¦__¦__¦__¦   Sheets
>
>I have made something also with XML and XSL
>------------------------------------------------------
>E:mail: tapio.markula@nic.fi
>http://www.nic.fi/~tapio1/index.html (Finnish)
>http://www.nic.fi/~tapio1/index_e.html (English)
>http://www.nic.fi/~tapio1/Opetus/ (CSS2)
>http://www.nic.fi/~tapio1/Teaching/ (CSS2)
>http://www.nic.fi/~tapio1/Opetus/XSL-new.html (XML)
>http://www.nic.fi/~tapio1/Teahing/XSL-new.html (XML)
>------------------------------------------------------
>
>
>

-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
 -- Unless explicitly so stated in the text, it does not represent an
    official position of Adobe Systems, Inc.
 -- Unless explicitly so stated in the text, it does not represent an
    official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
  Stephen Deach                            |  Sr Computer Scientist
  408-536-6521 (office)                    |  Adobe Systems Inc.
  408-537-4214 (fax)                       |  Mail Stop W15-424
  sdeach@adobe.com (no advertizing)        |  345 Park Ave
                                           |  San Jose, CA 95110-2704
                                           |  USA
----------------------------------------------------------------------------
-

Received on Monday, 7 February 2000 22:39:31 UTC