Re: XSL formatting model

[Chris Lilley <chris@xxxxxx>]

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