Subject: Re: [xsl] Prince XML vs Docbook From: "Liam R. E. Quin liam@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Thu, 18 Jan 2018 21:02:46 -0000 |
On Thu, 2018-01-18 at 18:15 +0000, Eliot Kimber ekimber@xxxxxxxxxxxx wrote: > I would disagree with your assessment that CSS pagination is not > easier than FO *if* there was appropriate how-to guidance available. We did a poor job (collectively) at tutorials and outreach for XML technology, both at W3C and in the wider community, and we now pay a price for that. > It would also help to have a less-like facility that could be easily > used with XSLT It's not too hard to implement (non-cascading) CSS custom properties ("variables") in XSLT, with a simple XML document to give the values. > Granted, working out the details of how to translate your source into > appropriate pages is inherently challenging. Yes - the syntax is (by and large) the easy part, although as with any batch formatting system, getting page numbers and headers under control can be a challenge. > But I think CSS's way of capturing the design details as > implementation artifacts is much more accessible to designers than > XSL-FO page masters and page sequence masters. With some appropriate > templating of page rules it could be pretty easy to define and > maintain. Yes, especially with flex and grid now in all major browsers. > Another practical issue, and one that should not be underestimated, > is the need to synthesize elements in source content to enable > generation of running headers and footers (more generally, any edge > region content). > > Because of the way CSS works you can't have an element that both > contributes its structured content to an edge region and is shown in > the main flow. This isn't entirely true, as you can use content: element(#foo) to reuse an element, but yes, only as a string value. > The XSLT+CSS approach separates the details of what *content* goes in > the running heads and the styling details (where it appears on the > page and how it's formatted in that context). > > Note also that for CSS pagination to work well the input really needs > to be HTML, not arbitrary XML. While CSS can, in theory, be applied > to arbitrary XML, in practice it doesn't really work, for a number of > reasons, not least of which is CSS's lack of support for namespace- > aware selection. CSS has namespace-aware selectors and has had for many years. It's in CSS 2.1 iirc. https://developer.mozilla.org/en-US/docs/Web/CSS/@namespace You have to use | rather than colon, as CSS usd : for something else, so you end up with @namespace h url(http://example.org/ns/hosiery) and then using h|sock { color: black; } > Leigh White's DITA for Print book serves as an excellent example of a > comprehensive how-to guide to doing complex pagination with non- > obvious technology from sophisticated XML source. Yay, and it's $165.93 on Amazon. I'll take ten... :) i found a PDF extract, looks like it might be very interesting > If we had a comparable book for CSS pagination I think most people > tasked with applying CSS for pagination would be able to be > productive with a minimum of pain. > > The challenge of course is finding someone to write such a book (and > keep it up to date as the technology evolves).... Maybe if i retire and am independently wealthy :) In the meantime see e.g. Rachel Andrew's book on flex and grid to get a feel for where things might be going - http://amzn.to/2rjY7oL [referrer link, make me rich!] Liam -- Liam Quin, W3C, http://www.w3.org/People/Quin/ Staff contact for Verifiable Claims WG, SVG WG, XQuery WG Web slave for http://www.fromoldbooks.org/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Prince XML vs Docbook, Eliot Kimber ekimber | Thread | Re: [xsl] Prince XML vs Docbook, Eliot Kimber ekimber |
Re: [xsl] Prince XML vs Docbook, Michael Kay mike@xxx | Date | Re: [xsl] Prince XML vs Docbook, Eliot Kimber ekimber |
Month |