Subject: RE: CSS and XSL
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Mon, 15 Feb 1999 17:32:05 -0500
HI Sinon,

By the way, did anyone read the 'worse-is-better' article?  (It's at  It sums up a lot of the
problems we've been talking about here quite nicely, though as an upstate
New Yorker I'm not completely fond of identifying myself as a New Jersey

I read the article with great interest. It does gives fuel to the fact that
XSL "transformation" module should be separated from XSL "formatting" module

On the CSS thing. I agree that some proposed construct are quite complicated
for human to write and obviously CSS is, considering the human facets, a lot
more easier to write and understand.

What is contrary to the New philosophy however is to have a style property
that has to be parsed with different constraint than the other properties.
It would be easier to have a kind of object/property set thing. An object
being marked up and having its property set expressed in the same manner. A)
it is easier to implement because you have only one parsing rule B) easier
to explain, because it is more obvious than saying bla bla bla except this
property that... bla bla. We bring an exception in the panorama. This said,
the only reasonable motive that I see why we would have a style property
expressed that way is for a retrofit reason. And for the first release of
HTML+CSS(XML) (named voyager) it seems reasonable (there is legacy out
there). But for SVG I don't understand because there is no legacy. In this
last case, we should have more the object/property set stuff with a simple
XML syntax because there is no retrofit to do - there is no legacy. So, for
HTML+CSS, I guess we don't have any choice, because of the legacy, to have
the style property and a embedded parsing rule different than XML which in
this case act as a container format. For XVG that's a different story
because, as soon as a SVG rendition tool is available I can use SVG for
rendition instead of HTML+CSS or in complement to HTML+CSS. If SVG has an
easy structure and an easy syntax (i.e XML) then the task is easy to
implement. If, however SVG has more than one syntax embedded in the other
the implementation is harder and as said in the article you mentioned, we
loose in the process. I agree on the fact that we should keep in mind two
principles: modularity and simplicity. These are the key success factors.

 XSL-List info and archive:

Current Thread