Subject: RE: CSS and XSL From: "Jelks Cabaniss" <jelks@xxxxxxxx> Date: Sat, 20 Feb 1999 14:46:10 -0500 |
Oren Ben-Kiki wrote: > >> The advantages are: > > > >> - Ease of generating CSS from XSL. XSS would be XML, and CSS isn't. > > > > Thank goodness. > > I assume I missed a smiley here. No. You saw the implicit one. :) > If not, does it mean you think that XML is bad in itself? Of course not. I think of XML as the best thing since unsliced bread. And (on that track) CSS the best thing since butter, with XTL (potentially) an awesome knife. :) > I'm also not thrilled by the angle bracket soup, but I'd > rather have a less then perfect common syntax then a set of three competing > ones, each with its own particular flaws. > > I'm an old fashioned UNIX hacker and fondly remember the days when I could > do complex operations by combining simple commands using ASCII text files > (or even better, pipes). I see in XML the potential for providing another > framework which would allow the same sort of modularity. If we keep styling > in a separate syntax, then operations manipulating style would be left out. You're saying that if style isn't expressed in XML, we won't be able to manipulate it? Take a look at DOM Level 2, at IE4, at DSSSL. In fact, wouldn't the "whole-world-is-XML" approach be more favored by monolithic program aficionados (you only have to use *one* parser for *everything*) than the Unix "separate pieces" approach. And though I'm not necessarily opposed-on-all-counts to expressing style in XML, I really haven't yet seen an XML approach that doesn't butcher the beauty and simplistic elegance of CSS. > >What does "transforming content to structure" mean? Sounds like > ASCII-to-Markup > > It means I can break my application into three parts. One part handles the > data model, regardless of any viewing issues. Another is concerned with > extracting the data to be viewed and reorganizing it to be comprehensible to > the user. A final part is concerned with the second-to-second dynamic > styling of the organized data - handling events, highlighting some data, > collapsing entries in trees, etc. OK, I see. One tree (what you called "content") transformed into another tree ("structure"), then that second tree styled. It's that third part that's got the masses rioting in the streets. > Using XSL as it is today, the last two phases are forced into one, which I > feel is a mistake. Using XML -> XSL -> CSS is better in this regard. I agree. > As you > pointed out, XML+CSS isn't well defined at the moment, and like you I'm not > aware of anyone who is working on this particular approach. Not officially, at least that I've seen, but in implementation, IE5b2 does support: 1) The <?xml-stylesheet ...?> PI (= HTML LINK) 2) ID and CLASS styling 3) Inline CSS (<element style="...">) of which online the first is "official". > I tossed this > idea here as a "heretical view" of how XSL could/should be defined, instead > of the current FO approach. No problem with your heresies, but I haven't yet seen a good reason for recasting CSS as XML, any more than I have seen good reasons for recasting bitmapped graphic formats or IP packets as XML. "The-whole-world-is-XML" mantra does have a certain appeal, but I think it's a rather shallow and myopic one. /Jelks XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: CSS/XML in IE5b2 - generated co, Chris Maden | Thread | CSS and XSL, Oren Ben-Kiki |
CSS/XML in IE5b2 - generated conten, John E. Simpson | Date | RE: Generating SVG, Jelks Cabaniss |
Month |