W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2000

Re: XSLfo or CSS3

From: Stephen Deach <sdeach@Adobe.COM>
Date: Thu, 03 Feb 2000 13:52:49 -0800
Message-Id: <>
To: xsl-editors@w3.org
For the xsl-editors archive only,
  This is Tapio's response to my e-mail of yesterday. It indicates he has
no interest in and no understanding of formatting requirements or
formatting models beyond basic galley/WP/browser formatting. It also shows
that he has little understanding of the capabilities and intended usage of
  At the advice of several WG members, I am not going to debate this issue
any further with him. I will continue to review any postings to determine
if he raises any substantive issues.

>X-Sender: tapio1@gamma.nic.fi
>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
>Date: Thu, 03 Feb 2000 11:05:33 +0200
>To: Stephen Deach <sdeach>
>From: Tapio Markula <tapio1@gamma.nic.fi>
>Subject: Re: XSLfo or CSS3
>At 20:12 2.2.2000 -0800, you wrote:
>>  You have sent several comments over the past week, and I have had some
>>problem determining what the specific issues were that bothered you. You
>>seem to dislike XSL-fo, but seem unable to describe why. 
>1) CSS can be used in HTML, XML and XSLT files. It keeps XML and HTML
>together. XSL-fo is only for XML. This is the main reason.
>2) CSS2 has already most of features of XSL-fo and in CSS3 is more same
>kind of
>features. 'display:block' makes the same as <fo:block>. ALL aural
>properties in  CSS2 and used in XLS-fo. WHY to make another language to the
>SAME task.
>>In one message,
>>you say that you don't like that XSL requires that you split layout and
>>styling into multiple streams, whereas in another you say thet XSL doesn't
>>allow you to split apart the specifications for structure, content, layout,
>>and styling. (I really don't understand the last statement, since XSL is
>>the first specification in this arena that defines separate structures for
>>pagination-layout vs. flow-styling)
>Examples, which I have read and tested, XSL-fo is used in the SAME file as
>XSLT or XSL fo makes alone the structure and layout. Anyway sturcture and
>layout are glued together like in HTML 3.2.
>I have made XSLT files, where XSL describe ONLY structure using templates,
>CSS describe the layout and XML contains the contents.
>>In addition
>>to being able to create output for a browser, people want a single
>>extensible formatting architecture and a single layout/styling language
>To separate layout/styling from structure language gives more flexible
>If styling/layout is among struture it means ALWAYS more code than by using
>separate layout/styling language. HTML 3.2 and XLS-fo attributes need much
>code compared to combined rules and declaration-blocks of CSS. It is easy
>to affect great exchanges to elements by using rule sets and large
>declaration-blocks. I hate to give layout/styling inside HTML of XSL
>elements. That's why I hope, that XSLT + CSS could at least leave together
>with XSL-fo.
>>that could support both paged and scrolling media, including: WAP 
>BUT todays WAP doesn't support any styling/layout language. CSS2 has media
>'handheld', but Nokia Communicator or Nokia WAP Mobilie Phone doesn't
>support it. Using XSLT + XML + CSS ors HTML + CSS could create pages both
>to large computer screens and handheld devices.
>>cards" for wireless delivery on pagers, phones, and palmtops), demand print
>>("for a print-friendly version, click here"),
>CSS2 has this possibility today, if it just be supported media="print"
>>magazines), and even retail catalogs and advertizing brochures. CSS not
>>only does not support most of the latter portion of this list, but it has
>>architectural limitations that prevent it from doing so or doing it well
>I don't have written, that CSS could do everything, but together with XSLT
>it could do more flexible way the same as XLST + XSL-fo. XSL-fo in not at
>all necessary language.
>>  If you don't need the ability to format paginated documents and/or
>>documents with multiple concurrent articles (or sidebars), then feel free
>>to use a simpler architecture (such as XSLT+CSS), 
>In what way XSLT+CSS is not enough. You might say, that TODAY CSS2 is not
>enough. This is true. In CSS2 is not enough pagination properties.
>BUT there is under developing CSS3, which has more of them. I just say,
>that CSS3 could have ALL, what XLS-fo have, but the CSS3 could have more
>use, because CSS can be used also with HTML documents.
>>people who do need or want a language that can deal with both complex-paged
>>media and scrollling media, and don't prevent them from getting the tools
>>they need to get thier job done.
>This in not my intention. BUT my intention is, that SEPARATE and COMMON
>language, CSS3 could be better choise than XLS-fo.
>> 1.) XSL and CSS are not competing standards, they are complementary.
>Yes in XSLT, but NOT	concerning XSL-fo!
>>have made a great effort to make them highly compatible at the property
>>level, while not breaking the ability to support thier target domains.
>Why put 'text-align:justify' - text-align="justified". It is dummy to
>exchange these. Authors has extra work to remember, what value is CSS and
>what in XSL-fo.
>> 2.) I have aleady commented on your assertion regarding the splitting of
>>styling & layout & content. The XSL stylesheet is a separate document from
>>the structure/content and the XSL stylesheet can be modularized to split
>>the layout from the styling and to further modularize both styling and
>>layout through the use of xsl:include directives.
>You meant, that XSL-fo and XSLT could be in separate files. That is true, but
>nobody has not make these kinds of example. You must admit, because CSS
>doesn't need elements, it is more compact to write. I just don't like
>element-based styling/layout language. CSS use JavaScript resemble syntax,
>which is fast to write and edit.
>> 3.) You assert that XSL splits the web into XML & HTML, and further state
>>that XSL can only be used with XML, this is also not true. Nearly any HTML
>>document can be transformed into well-formed XHTML via tools like the W3C
>>tidy parser. Any well formed XHTML can be processed by XSLT & mapped to
>But XSL-fo works only with XML-browsers. What makes XSL-fo + XML? XML +
>XSLT + CSS can be made XHTML + CSS files with some server application. My
>server doesn't support any translation. IF XSL-fo is used XSL-fo + XML
>should be able to tranlate at leasti into XHTML with HTML 3.2 attributes.
>> 4.) CSS defines a method for finding elements and assigning stylesets to
>>those elements through its selectors. XSL does this assignment though XSLT.
>XSLT + and XSL-fo are heavy for that.
>>For simple cases, the CSS strategy may be easier & more compact,
>That is my point.
>>but XSLT
>>allows for a much broader range of context-selector specifications than is
>>allowed in CSS. 
>Then why just develop CSS + XSLT to work properly in every situation.
>It is not intended that one hand-code XSL-FOs.
>> 5.) XSL also does not rely on built-in semantics of HTML to do portions of
>>its presentation, such as the visited/selected example you present. 
>Yes - this is problem by using CSS in XML, I admit. If the final document
>is XHTML this is not a problem, but if is another XML-document, it is,
>because in CSS :link, :visited etc. are designed to rely on build-in
>semantics. MS has "resolved" this with proprietary extenstion to CSS. But
>this is the only major problem. Why not try solve this in CSS3?
>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 Thursday, 3 February 2000 16:49:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:17 UTC