Slashdot Mirror
Printing XML: Why CSS Is Better than XSL
An anonymous contributor writes "XML.com just published an article titled Printing XML: Why CSS Is Better than XSL written by Michael Day and Håkon Wium Lie. The article was written in response to Norm Walsh's claim that CSS will never fix [printing]. Did you hear me? CSS will never fix it!. The article shows how a 100-line CSS style sheet gives you the same formatted version of W3C's Webarch as the 1000-line XSL style sheet by using Prince."
I agree. CSS is definitely better... but when you have to rely upon IE to update itself to the latest standard (much less a standard that is 5 years old) it becomes a bit tedious.
Frankly, I think the W3C should act like supreme overlord and take a bullwhip to all browser developers who can't stay up to standard.
I can just see Bill Gates bent over and bare assed in a W3C hazing ritual saying 'Thank you sir! May I have another?'
This is my sig. There are many like it but this one is mine.
If you check them out, at least one savings in the CSS is that it hard-codes the page size for a single size.
If you look at the XSL, it selects different text sizes for different page sizes.
Thus I would have to say - have they tried printing both examples using different page sizes? Because I am pretty sure the CSS version will be a postage stamp in the middle of an A0 page.
Also from quick examination it looked like the XSL is more flexible in other ways, you can pass in all sorts of parameteres like margins.
Basically - sure the XSL is longer, but also more flexible in terms of use. Since you are only going to write it once (that is unless you want multiple page sizes in which case you are going to have many CSS files) what does it matter if there is a little code-size increase?
Furthermore the XSL could itself be transformed in various interesting ways for special modifications, a task harder to do with CSS. And you could include things like the paper-size->font-size mapping in seperate files to keep the size down and the file more readable (though I find the XSL perfectly readable - after having used XSL for a while, admittedly!).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
From TFA:
More recently, a W3C Candidate Recommendation (called CSS3 Paged Media Module) added functionality to describe headers, footers, and more...
The big difference is that XSL provides the tools to perform this transformation - from XHTML to a printable layout - without needing to change the standard itself. The same goes for the argument made about page sizes, which are built into the latest CSS and which have to be handled manually with XSL.
Now, once you have wide support for the latest CSS (and who knows how long that will take), I would wholeheartedly agree that it would be a better choice for printing as shown here. The fact of the matter seems to be that they're comparing what you can do today, with a little work, using XSL transforms, to what you may be able to do tomorrow with a proposed dedicated language. I'd be pretty surprised if the latter couldn't do what its designed to do better than a general purpose language.
At least, that's the way I see it. So, there's some good stuff coming down the pipe with CSS. That's worth knowing about. But until it has wide support, there's XSLT. And that's worth knowing about as well, and a damn sight more useful - for now.
You're special forces then? That's great! I just love your olympics!
As the old saying goes ... those who do not understand TeX are doomed to continually re-invent it ... badly.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
The same argument could be applied to RDBMS: "Stored Procs are harder to use, so move the logic into the PHP code!!!" or Languages: "Pointers are hard to use, so VB.NET r0xx0rs over C!!!!"
My experience with the whole mess is that, yes, XSL-FO->PDF is harder to set up, but I get the same output every time. We tried to use CSS, and all it took to screw up the works was have somone set their browser margins or font size differently. Or use a non-CSS-compliant browser. We don't have control over the user's browser, but if we output to PDF, we have total control. Oh, but it is harder to use the latter, so forget it.
Q: How can you tell if a website was designed by a know-nothing monkey? A: "This site best viewed in 800x600, 1024x768, etc."
Yeah, right.
I think it's safe to say that TeX and LaTeX own the typesetting domain. Some reasons why perhaps
;-)
1. It's old, mature and stable
2. LaTeX makes TeX really easy to work with
3. The output is related to the input, not the machine you are working on.
4. Gives you wicked control over positioning, size, orientation, etc.
5. Great support for equations, figures and other oddities that things like Word manages to screw up.
6. Most TeX distros [like tetex] are FREE and open source. No shelling out the MSFT tax to use Word
The only big downside to LaTeX is that occasionally it automagically places things in a less than desired fashion [figures I mean] and you have to manually tweak it. But I'd say for 99% of what math/crypto people do [for instance] LaTeX handles it perfectly.
Tom
Someday, I'll have a real sig.
There's already a lot of discussion here about how IE's XSL transforms (and CSS support in printing) both suck, and how a proper workflow for XSL involves a server-side transform.
The authors of their CSS Rocks article are imagining that you're going to use software like Prince, (software that one of them created) to apply CSS3 rules to XML and get PDFs out of them.
Another way to say this is that they're not talking about how to fix the browser -> print workflow in this article (although one of the authors works for Opera, so I imagine he's thinking about it). They're talking about easy ways to transform XML to PDFs, and discussing why you might use CSS to do such a thing.
This courteous and friendly rationalizing of the slashdot editor's inflammatory post has been brought to you by my company, which is paying me for the time I use to write this. The opinions, of course, are mine only.
Please stop trying to build up this markup language, which annotates documents with suggestions as to how they might be displayed, into a typesetting system. Please get a typesetting system instead, and use formats such as eps and latex that are relevant to the task.
Thank you.
Also please stop using XML to represent arbitrary data. It's a markup language. It annotates and divides text. It does not extend easily to representing all data in all contexts, and when you try and make it do that, you wind up with syntax like '[CDATA['.
Thank you for your co-operation and enjoy your day. This has been a Public Service Rant brought to you by Diet Coke.
Whence? Hence. Whither? Thither.
In nice, big text. Way to hold the the XSL fort, guys!
Jeremy
Looking for a Python IRC bot?
It doesn't matter which standard (CSS or XSL) an author uses for styling pages for print if there aren't many widely-used applications (e.g. web browsers) that have good support for printing. Even Firefox, which arguably has the best standards compliance, has a lot of bugs in its print layout subsystem.
Though I do have to agree with the article, in principle, that CSS is fully capable of doing the job when it comes to producing printable page layout, if we're going to be banging on a drum, let's bang on the "let's get these damn browsers to support printing better!" drum first. Because even if I create a CSS stylesheet that should produce beautiful printed pages, it doesn't do me a lot of good if I can't actually print them that way.
Despite what EULAs say, most software is sold, not licensed.
The bottom line (at least for me): if you can do it with CSS, do it with CSS. But there are some cases where you will need XSLT.
I stop reading when I saw that XSL examples are XSL:FO examples. XSL:FO is set of XML definitions on top of XSL to address the PRINT world's requirements. As such, it contains ALL the tags and attributes needed by this industry and provides EXTREME flexibilty, at a price: verbosity. However, the article does simple CSS formatting vs XSL:FO where XSL:FO is obviously not needed for that usage. So it's basically taking a hammer to kill a fly, maybe drop a nuke on it. Nonsense...
He is not only using a lot of CSS3 in his examples, but he is using things that does not even look to become parts of CSS3. For instance the content:target-counter was in a working draft of the css3 paged module, but have been withdrawn from the latest version.