[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: XSL formatting model
Subject: Re: XSL formatting model From: Chris Lilley <chris@xxxxxx> Date: Wed, 27 May 1998 18:24:38 +0200 |
Lee Fife wrote: > > I'm trying to understand what appears to be the WG's current intention > to create a new formatting model, based on flow objects, for web output > that is not equivalent to HTML 4 + CSS 2. It is the intention to have a formatting model based on flow objects. It is not a new model, particularly, nor is it inconsistent with the CSS2 model. Indeed, significant work is being done to ensure that CSS and XSL are syntaxes that express the same underlying model. (I will not speak of the HTML formatting model, since it does not actually have one any more than it has "HTML flow objects"). > Naively, this seems to be bad idea. Doesn't build off existing practice > and implementations, goes against the market direction, complicates XSL > and possibly reduces its acceptance. The contrary. It does build off existing practice, with both CSS2 and with DSSSL implementations such as Jade, which are used for real-world publishing both online and print today. A single underlying model is also calculated to simplify implementation and use, and to increase acceptance. > > But, the folks on the WG are bright and experienced. I'm sure they're > not heading in this direction w/o thought. Thanks ;-) We are not heading off in some new untried direction, nor are we introducing gratuitous incompatibility with existing practice. W are adding new functionality, functionality that users clearly need. > So, explanation please? What's the rationale for abandoning the proven > and deployed formatting model represented by HTML/CSS Abandong it would certainly be a bad idea. I am happy to report that we are not doing that. > and attempting to > develop a new model? (The only explanation I've seen offered so far is > that the original XSL note described generating really ugly HTML that > wouldn't behave well in various display environments. Generating HTML that consists merely of font and br tags and tables can give a very pretty but totally inacessible result, particularly if done server side. And generating a one inch margin by writing a table with a 72 (or 96, you choose) pixel empty first column could not be described as being consistent with CSS ;-) I suggest looking at the CSS2 Recommendation where it talks about the underlying visual rendering model. > The obvious fix > here is to generate better HTML, not to abandon the currently proven web > display model. Generating HTML can certainly be improved. Generating a bug-for-bug compatible quirk-for-quirk compatible "HTML renderer" is a vast software engineering effort, I have spoken to folks who have done it. Generating a CSS renderer is not especially hard, nor does it necessarily add overmuch bloat to the code size (again, based on implementation expreience communicated to me). The goal with XSL is to have a single underlying model of whic both CSS and XSL are expressions; thus a browser or a print formatter or a stylesheet editor program can implement the underlying model and then readilly implement CSS or XSL or both (save as CSS, Save as XSL .... You raise valid concerns, Lee, but as you hoped the decisions have not been taken lightly or without thought or attention to implementation experience. -- Chris Chair, CSS&FP working group Member, XSL working group XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL formatting model, Paul Prescod | Thread | Re: XSL formatting model, Sean Russell |
RE: XSL formatting model, Richard Lander | Date | RE: XML Transformation Language (wa, Rob McDougall |
Month |
Keywords