Subject: RE: CSS and XSL From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Mon, 15 Feb 1999 17:32:05 -0500 |
HI Sinon, <YourComment> By the way, did anyone read the 'worse-is-better' article? (It's at http://www.naggum.no/worse-is-better.html.) 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 sympathizer. </YourComment> <Reply> 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. </Reply> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: CSS and XSL, Simon St.Laurent | Thread | CSS, XSL, and an RDF-like approach, Simon St.Laurent |
RE: CSS and XSL, Jelks Cabaniss | Date | For Each in XSL, Livingstone, Stephen |
Month |