OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Future of XSL-FO at W3C??

[ Lists Home | Date Index | Thread Index ]

(Resending this one, it didn't came through to the list)

J.Pietschmann wrote:

 > m batsis wrote:
 >
 >> So a formal mapping between CSS and FO properties is the way to go by
 >>
 > You'll find it in the XSLFO spec.


My point exactly.


 >> To return back to my question on inheritance, perhaps you are 
talking about what I think of as groupings, for example the subset of 
background properties.
 >
 >
 >
 > No, I was talking about how presentational properties are tacked to
 > nodes in the XML tree. Usually nodes inherit certain properties from
 > their ancestors. Two problems:
 > - Which properties are inherited, and where is inheritance blocked.


I don't think there are differences since the FO property definitions 
come directly from the CSS specs, unless you go beyond those and into 
the actual tree of the XML document, mostly meaning containers (i.e. div 
elements in XHTML) mapped to FO blocks.


 > - The interaction of inheritance, shorthand evaluation and default
 >   values.


I fail to understand "interaction of inheritance". Shorthand properties 
are usually evaluated after being broken up into more specific 
properties. That's why I mentioned the importance of document order.

 > - If the properties are declared separately and connected to the tree
 >   by a matching mechanism, it has to be defined how this is done. For
 >   example
 >    div.sect { margin-top: 3pt }
 >    div { margin: 12pt }
 > Unfortunately, CSS mixes all aspects and thereby muddles what
 > "inheritance" means.


CSS is pretty clear on it's view of cascade and inheritance. A div.sect 
will have a {margin:3pt,12pt,12pt,12pt} in a sequence of 
top,right,bottom,left.

But your example clearly points out an issue, which is the need for 
algorithms that will efficiently harvest FO style properties and group 
them under CSS selector statements, meaning it is easy to convert from 
CSS to FO but not vice versa. I expect people to edit having the CSS 
version as a reference (witch is where the benefit exists anyway) and 
produce FO from that.

If you have two-way conversion in mind I'm sure many examples from FO to 
CSS can demonstrate problems but I don't see conversions of FO to CSS 
mandatory or even of any benefit at all. IMHO, all the benefits of CSS 
is on the (easy and convinient) authoring side, where the document keeps 
changing.

Manos







 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS