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.
Free for any purpose eh? This will go well for the interface to my baby mulching machine.
Is XML with CSS better than TeX, or Postscript for that matter? Can it be? I have never seen a high quality print from anything other than *TeX, and that includes XML/XHTML/HTML, so I figured out that (XHT|HT|X)ML is not a typesetting system. Is that not the case?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
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!
Does XSL suffer the same cross-browser incompatibilities? This I don't know, and while I love CSS, if XSL was better at cross-browser homogenity(sic?) I could see that being a big feature.
As a previous poster noted, though, a better solution would be for Microsoft to fix IE so it supported the wc3 recommendations....
philcrissman.com.
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.
XSL is supposed to take in semantic content and transform it into presentation for the web. If you're going to make gross generalizations, one ought to compare XSL to templating engines. The two technologies are meant to work in tandem
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.
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!".
Let the hair pulling and the name calling begin.
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?
XSL wasn't meant for formatting and printing. It was meant for converting XML into other XML formats (such as XHTML + CSS helloooo???)
Comparing XSL vs. CSS is like comparing Table-based design with Table AND CSS-based design.
(X)HTML's Document Object Model has default styles ("default" CSS if you prefer) assigned to each element. Of course using CSS is necessary.
And the reason many XSLT stylesheets are so long is because of the stupid design imposed on them (non-changeable variables, result-tree-fragments, inability to eval an xpath expression... ok who was the genius who came out with these ideas, anyway?)
Unfortunately, current browsers cannot do ALL the formatting. Try turning off IE's header and footer using CSS. Or customizing your own header and footer, or print landscape instead of portrait.
Let's hope that CSS3 solves these problems - but until then, server-side PDF generation is the solution.
Anyway if browsers had supported XSL, it would be a mainstream component of the web today. We would have marvelous things like client-side inclusion (I've done it with XSLT alone, _NO_ javascript!), bandwidth savings... (imagine that with Google!)
In the end it became a pipedream due to the lack of browser support.
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.
Lyx... http://www.lyx.org/ is my favoite.
It's the reason I switched to linux.
It's the reson I bought an iBook.
It's the reson I passed some tough courses.
Down with WYSIWYG!
-=fshalor
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...
When the SVG spec was first published, I combed over it pretty well. This was when basically no renderers were active enough to cover the whole spec. Yet, the W3C had screenshots. They had screenshots for some rather confusing or unclarified attributes of certain elements. These were things you couldn't explain in words well, but moreso with illustrations.
http://zengarden.20megsfree.com/
It's enough to create TOC, list of figuires, footnotes, what have you. Enjoy: CSS3.
In retrospect, my comments about CSS and printing seem snarky and sound like hubris. My apologies. I'll take a closer look at the XML.com article and try to post a more reasoned reply. Not that I expect that'll get slashdotted :-).
--norm
Or $0 per individual for a personal license. $2,000 per server for a business really isn't that much.
And THANK YOU to the grandparent! I was getting annoyed at all the long discussions about how IE does or doesn't support whatever. It's irrelevant!
Thinkin' Lincoln - a web comic of presidential proportions
The web is changing. It's not all about what browser we are using on a given wintel/linux/mac computer. It's about providing content in an easily parsable format. Presentation should always come a second to well structured, meaningful markup.
What about disabled access to your webpages through some speech browser and the like. What about mobile devices. Provide your content in a well structured format and you can be sure any (half modern) current device can see your pages as well as anything in the future.
The web is not a print medium. Design your sites so slight differences in spacing etc. are irrelevant. A well designed CSS-driven site will degrade nicely in Netscape 4 (basically @import to exclude it and other archaic browsers) and at the same time be accessible to everyone on any device.
A couple of years ago I would have agreed with you. Now the average browser is more than capable of displaying CSS based designs. Alright CSS may require a few hacks here and there for IE and such but a few nasty bits of CSS is far more preferable than some hacked together HTML using tables for layouts.
Two competing technical ideas so that everyone can line up behind one or the other and argue which is better.
I'm really tired of seeing everyone here just politely agreeing with one another in such a single-minded way.
Ever since the debates over vi/emacs, linux/windows, tastes great/less filling, etc. were all settled, there just haven't been any good arguments here.
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.
First off, it's Quark XPress.
Second, it's only recently that Quark has been able to use anything other than a lousy bitmap preview for placed art. The majority of XPress users never upgraded from v4, and so get cruddy bitmaps (unless they license an XTension which then litters their HD w/ preview files) and a weird shift from nice anti-aliased type to blocky bitmaps when editing text at certain sizes).
Thirdly, Quark is incredibly limited in terms of the glyphs which it can access, so What You See Is All You're Going to Get, and you ain't gonna automatically get spiffy ligatures in it from OpenType and AAT fonts (manually inserting ligatures pulled in from ``Expert fonts'' is _so_ 20th century (and something I found tedious immediately after purchasing Adobe Garamond back in 1989) and fixing them by search-replacing in XPress Tags is a poor solution).
And lastly, Quark still has a brain-dead, one-line at at time H&J algorithm --- at least Adobe had the sense to make use of TeX's algorithm when they developed InDesign.
William
Sphinx of black quartz, judge my vow.
XML, TeX, and PostScript are all designed for slightly different purposes. XML is good as an interchange format for structured data. Its main strength is that it is easy to transform XML into other formats. XHTML can be used to store semantic information which can have a specific presentation applied to it using CSS. There is no theoretical reason why this couldn't look as nice as that produced by TeX, but practically it usually doesn't since it is usually typeset by browsers which require their layout engines to run in real time.
TeX and PS are both Turing-complete languages with slightly different purposes. TeX is usually used with the LaTeX macros as a semantic markup language. The advantage of this is that it is much easier to type than XML. \section{This is a section heading} would be the equivalent of <h2>This is a section headong</h2>. I also find LaTeX code to be more human-readable. PS (and it's non-Turing-complete little brother PDF) are specifically designed to produce page layouts - they do not contain semantic information at all. It is relatively easy to convert between LaTeX and HTML, and it is also relatively easy to render either as PS or PDF. Converting in the opposite direction is more tricky.
I am TheRaven on Soylent News
XeTeX is very interesting and a good project. However, it is extremely limited to the Macintosh due to being hardwired to the OS X font engine (making it somewhat useless to most of the world). Also, it suffers from the TeX problem that there is no consistent approach to development at all that would encompass larger parts of the toolchain beyond the mere engine. If you need Unicode and additional tools, even similar ones like BibTeX, you'll quickly find out that they are either 8-bit, that the non-8-bit versions are quick undocumented hacks done by persons who are now unavailable, or that it's hell of a lot of work to get sensible output. It's possible, but the way there is long and thorny, and it feel like being in the 1980's again. While the TeX world is certainly better off with XeTeX than without it, it is really quite a limited solution.
TeX is a shining example of how not to do a large open-source software project; the complete lack of coordination has made development somewhat difficult and frustrating. If you look at those parts of TeX where coordination is taking place (ConTeXt, for example), it's evident that it could have been different. With LaTeX, the only reasons that keep it alive are inertia, the relatively large user base and the somewhat futile development efforts of some uncompromising developers (whom I admire for their commitment) that are struggling against fifteen years of uncoordinated development. Myself, I'm using ConTeXt now, it simply has less compatibility problems, is less frustrating and gives better layout.
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)