Re: W3C-transformation language petition

[Ian Hickson <py8ieh@xxxxxxxxxx>]

This is my first post here. I've been lurking for some time, and I
feel there are some misunderstandings within the XSL community as to
what CSS can do and especially how its syntax works.

So I'll admit it upfront: I am a strong supporter of CSS. However, I
also quite like XSL. I just haven't had as much experience with it.

And yes, this post is off-topic. (Not a good start, I know.)
Hopefully, though, it should clear up some of these misunderstanding I
allege are present here. If this thread continues, I strongly
recommend it be moved to www-style.

On Tue, 2 Mar 1999, Oren Ben-Kiki wrote:
> Instead, we should worry about the right way to structure XML
> application with graphical display. Should we use the XSL/FO
> approach or the CSS approach (possibly enhanced by "XTL")? The W3C
> hasn't decided, otherwise it wouldn't be promoting both XSL and CSS.

What about an aural rendition?

Will XSL be able to cope with alternative (non graphic) media? CSS
can. This is quite an important issue.


> The only problem is that CSS does not provide the full set of
> attributes necessary.

Quite seriously, what is it that in the opinion of FO proponents is
missing from CSS? (Other than tree transformation, obviously.)


And now the *really* off-topic part:

> And, of course, the syntax of CSS should be replaced by an XML
> compliant one :-)

I know that some people feel this quite strongly. 

The reasons I have seen put forward basically boil down to "You don't
need Yet Another Parser".

The syntaxes I have then seen used are similar to this:

    <css:style>
       <css:import url="..." media="projection tv">
       <css:media media="screen print">
          <css:rule pattern="P:first-child + P EM"
                    font-style="italic"
                    text-decoration="underline overline"
                    margin-left="3px"
                    margin-right="3px">
       </css:media>
    </css:style>

Besides the problem of the "rule" element having a gazillion
attributes in the DTD, and the fact that shorthand properties *cannot*
be dropped (they do a lot more than just stand in for other
properties: they also reset related properties in one go), there is
the parsing problem.

Anybody who honestly believes that the above only requires an XML
parser to parse is strongly mistaken. For example:

    <css:import url="..." media="projection tv">

The media attribute needs parsing into space separated keywords.

    <css:rule pattern="P:first-child + P EM"

The pattern attribute needs some serious parsing, which cannot
(AFAICT) be spelled out in XML easily (and certainly not as tersely).

                    text-decoration="underline overline"

And some more parsing needed in the text-decoration attribute.

                    margin-left="3px"
                    margin-right="3px">

Yet more non XML parsing, to separate the units from the number.

Since a specialised parser is going to have to exist *anyway*, why the
heck not use a CSS parser (and there is one currently available for
free in the mozilla codebase) and parse the current, cleaner, syntax?

    <style type="text/css">
       @import "..." projection, tv;
       @media screen, print {
          P:first-child + P EM {
              font-style: italic;
	      text-decoration: underline overline;
	      margin-left: 3px;
 	      margin-right: 3px; }
       }
    </style>

The above is directly equivalent to the XML version higher up. Notice how
*every* single keyword appears in both the CSS and XML versions, but how
the CSS one implies almost all the XML-only syntax.

Furthermore, XML does not define how errors should be dealt with,
which is a rather big constraint on future-proofing. CSS has extremely
specific rules for error handling.

For example, the following stylesheet:

   P { background: white; lighting: green 3% 5%; text-indent: 2em;  }

...contains an invalid declaration (the 'lighting' bit), so CSS
parsers would carefully ignore just that bit. This would result in the
following style sheet being read:

   P { background: white; text-indent: 2em;  }

This was carefully designed to make sure the language was future-proofed.
In CSS-as-XML, the following:

   <css:rule pattern="P" background="white" lighting="green 3% 5%"
             text-indent="2em">

...contains an unrecognised attribute and so the results are
undefined (as per XML, section 1.2).


There is also a semantic reason why CSS should not be written in an
XML syntax: XML documents represent trees. CSS does *not* have a tree
structure. It has a structure well designed to _decorate_ such trees.


Another problem with the concept of using XSL to style documents is that
XSL is not, AFAICT, dynamic (unless you go in with the DOM and directly
change the tree structure, which is quite a drastic thing to do, and
certainly isn't quick and easy). Once the tree has been transformed into a
set of FO elements, you are stuck with that tree, and in particular you
are stuck with that style. With CSS, you can easily change the styles
merely by using the DOM (level 2, currently in draft stage just like XSL
itself).

Personally, I think I will be using XSL mainly to transform the
document so that it contains a structure suitable for formatting.

For example, if I had the following XHTML:

   <?xml version="1.0">
   <!-- ... -->
    <h1>Title</h1>
   <!-- ... -->

...and I wanted to style the H1 with *two* borders, then I could
either go the FO way, and lose all structure, or I could use the
transformation part to add a DIV around the H1, making it:

   <?xml version="1.0">
   <!-- ... -->
    <div class="h1"><h1>Title</h1></div>
   <!-- ... -->
 
...and then style the two elements using CSS:

   div.h1 { border: solid red; }
   h1     { border: solid green; }

This conserves the structure (even if it pollutes it a bit), while
using a very simple formatting language.


Note. All this also applies to the question of why styles in SVG
should be expressed in a CSS-like syntax and not an XML syntax.

Furthermore, keeping the semantics of SVG will be very important -
that is to say, that with an XSL stylesheet applied to an SVG
document, the output *must* be SVG (it cannot be FO, since FOs do not
have the relevant concepts). And then the *only* way to style it is a
CSS-like tree decoration language.

-- 
Ian Hickson



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list