Re: XSLfo or CSS3

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

  If I was developing a styling language that was only targeted for today's
browsers and at single-article documents (or at most ones where the
articles are presented in sequence), then I would probably agree that a
limited and straightforward extension to CSS would be adequate.

  However, XSL-FO was developed in response to needs [expressed at many
sessions on reuse and repurposing at multiple major conferences over the
past 5-or-so years (such as the WWW conferences, GCA's XML-'##/Markup-'##
series, and the Seybold conferences)] for a single styling language that
can be used across a wide variety of media and document types. In addition
to being able to create output for a browser, people want a single
extensible formatting architecture and a single layout/styling language
that could support both paged and scrolling media, including: WAP ("index
cards" for wireless delivery on pagers, phones, and palmtops), demand print
("for a print-friendly version, click here"), long documents
(specifications and reports), DB reports and transaction confirmations,
"slide" shows and similar presentations, industrial catalogs & directories,
books (manuals, textbooks, cooking books, novels; even "art books"), forms
(paper and online), multi-article documents (newsletters, newspapers,
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,
since it is basically a method for decorating/styling a single controlling
content tree.

  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), but don't ignore those
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.

You make several statements that I believe are incorrect. 
 1.) XSL and CSS are not competing standards, they are complementary. We
have made a great effort to make them highly compatible at the property
level, while not breaking the ability to support thier target domains.
 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.
 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
XSL-FO.
 4.) CSS defines a method for finding elements and assigning stylesets to
those elements through its selectors. XSL does this assignment though XSLT.
For simple cases, the CSS strategy may be easier & more compact, but XSLT
allows for a much broader range of context-selector specifications than is
allowed in CSS. 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. This is
exactly one of the issues that XML+XSL was designed to address, to allow
for extensibility that was not tied to adding a new tag to all browser
implementations. This state-coupled presentation capability is supported,
in a more generalizable manner, through the multi-switch and
multi-properties objects in XSL.



At 12:14 2000-02-02 +0200, Tapio Markula wrote:
>I don't like that, XSL fo is competing system to CSS2 and CSS3. XSL fo has
>quite the same matters as CSS3. But it can be used only with XML. XSLfo
>divides the Internet into HTML and XML, because the is not common
>formatting and layout language.
>
>In HTML 4.0 + CSS structure and contents can be separated from presentation.
>in XSLT + XML + CSS stucture, contents and presentation can be in different
>files  as different modules.
>
>in XSLfo + XML this is not the matter. Structure and presentation are
>together. Just the content is separate. In my mind XSLfo is NOT the most
>flexible system.
>It use HTML resemblance attributes. In CSS can use grouped rules and
>grouped properties in declaration-block.  For example:
>
>
>.kehys-ala a, .kehys-ala a:link, .kehys-ala a:visited,  .kehys-ala a:hover,
>.kehys-ala a:active, .kehys-ala a:focus, .kehys2 a, .kehys2  a:link,
>.kehys2 a:visited,  .kehys2 a:hover, .kehys2 a:active, .kehys2 a:focus,
>.kehys-ala2 a, .kehys-ala2 a:link, .kehys-ala2 a:visited,  .kehys-ala2
>a:hover, .kehys-ala2 a:active, .kehys-ala2 a:focus
>{display:block;margin-right:1px;text-decoration: none}
>
>XSLfo need much more code to express the same! 
>
>In my mind it would be much more reasonable to develop CSS3 common layout
>and formatting language to HTML, XHTML, XML and XSLT files that use two
>system.
>
>Could you discuss about this matter.
>------------------------------------------------------
>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)
>------------------------------------------------------

By the way, several of these links are dead or have spelling errors
(Teahing vs Teaching, for example). Also, the www.nic.fi server was down
over most of the weekend.

>
>
>

-----------------------------------------------------------------------------
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 Wednesday, 2 February 2000 23:09:20 UTC