Marcello wrote:
Jonathan Ingram wrote:
I'm not sure any use of XSLT can be called simple :). I've tried reading the spec, and I'm still recovering from the headaches. Fortunately there are easier ways to style (rather than transform) XML, using CSS. This is very well supported in all the Mozilla derivatives. While XSLT is something I'm going to have to look at eventually, for the moment I'm happy with CSS :).
CSS, while simpler, is less powerful and gives you only HTML.
CSS can be applied to any XML markup for viewing on web standards browsers, but because current CSS is limited there are certain HTML functions (tags) it simply won't be able to enable, or to enable cleanly. In CSS 'display', for instance, there is no value for identifying when some XML element represents an object/image, nor a hypertext link/anchor. Obviously, there is no 'display' value for an inline note because HTML never supported this. (We find markup for inline notes in the TEI and DocBook vocabularies. Note that CSS can move a span of inline text to the side in its own box, I've tested it out myself, but IE6 unfortunately does not recognize the needed CSS so in IE6 the inline note stays inline, not a good thing.) Of course, one can use XLink for object/image embedding and anchors (and XLink makes more sense anyway than using CSS since it is a vocabulary-independent means to embed objects and enable links), but then current web browsers are very deficient in XLink support (Mozilla has very limited XLink support -- haven't tested FireFox yet -- while IE and Opera have zero XLink support.) The OpenReader System 1.0, should it become a reality (and we are working on it -- we've made great strides in the last few weeks in garnering fairly high-level support), intends to fully support the more important parts of the XLink specification in version 1.0. We may also add one or more custom CSS values to 'display' to emulate links/ anchors, objects/images and inline notes (OpenReader will include a facility to open 'booklets' to display non-inline content, in part to support OEBPS which enables this cool ebook feature.) We also plan to investigate a future version of OpenReader to *natively* support TEI-Lite or some subset of TEI (including handling inline notes which will be trivial for OpenReader to handle.) We may even develop a next-generation styling language to address the deficiencies of current CSS2 and CSS3 but which doesn't have the complexity of XSLT/XSL-FO. The problem with CSS is its ties to the HTML paradigm and legacy support. In OpenReader, we are freeing ourselves from these legacy issues and thus can think outside the box and move on to the next generation web browser -- in essence to go beyond HTML. Jon Noring OpenReader: http://www.openreader.org/