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."

Tru Dat

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?'

Re:Tru Dat

That's no enforcement, that's $250 a hour!

Oh, did I just make a silly comment? Sorry... (again)

Re:Tru Dat

Right, but this would be a damn sight more useful if IE actually supported it as well. Right now our webapps - and many others - have a "Print" option on each screen which generally renders a server-side PDF version of the information they're looking at. Its the only way to guarantee a decent hardcopy. Using this to do the transformation client-side would be really great - if it was supported in the standard XHTML viewers (ie: webbrowsers).

Even better, because there's no need to use the intermediate PDF step, instead the user would just print from their browser and they'd get the nicely formatted output pages. Ideally things like page size would be set from the print dialog, et cetera, for best transparency rather than being hardcoded into the CSS at all, something you need if you're dumping to PDF instead of going directly to a printer.

Re:Tru Dat

Its certainly ironic when I see one of the best "built in" SVG parsers, present not on a computer, but on a Mobile Phone (SonyEricsson S700i), yet all the viewers i see in IE seem to have some faults here or there.

Re:Tru Dat

There are some obscure corners of CSS2 that the main non-IE browsers can't handle or don't handle well, but for the most part they're compliant. I've never needed something they don't support. CSS3 is an entirely different ballgame, though. No browser even suports half of it, AFAIK.

Re:Tru Dat

I agree. CSS is definitely better...

For some things. XSL is much more widely scoped, (from the article), "Turing-complete language which, in principle, can be used for all programming tasks and is particularly suited for document transformations."

In the case of document presentation CSS is indeed a challenger, but mostly if the document is static. XSL has loops, branching, conditionals, and templates (akin to functions). If you have a report with some complex logic, ie. if this number is below a threshold, print this warning, otherwise show this table. Of course you could always do all transformations and logic before the final rendering step, but in a lot of cases it's easier to do it purely XSL. Yes, you could always bring Java-script or some other html-based functionality, but that's more than just CSS.

Furthermore, there was probably a number a transformations you've already done to get the data that you need. A more suiting comparision would be with XSL:FO and CSS, but again, they both have their place. Furthermore you can imbed graphics with SVG and tools like FOP will automatically render them. To say that CSS is definitely better is naive.

As in most other times when people compare languages, each has it strengths, and straight up conclusions (CSS is better!) is most often an apples to oranges comparison.

Re:Tru Dat

Can you tell me of any example where it would be easier to use XSL rather than just some CSS spit out based on some logic that something like PHP handles?

I have a large XML document. I want a PDF report of that information. With FOP I can write a couple stylesheets and get a PDF without having to use a browser.

My view is, why throw yet another programming language into the mix, just to do output?

If you're dealing in XML already the traditional route is XSL. If HTML than CSS+whatever. XHTML? Maybe XSL for transformations and CSS for formatting. But do you see that there are different problems that require different tools?

If people designed web apps like some advocate...

Web apps aren't the only apps. That's what I'm saying. Again, different problems require different tools.

you'd have to work in a million different langauges,

If you are a descent programmer, the languages don't matter. After you learn a few you pick up new ones quickly. You use the best ones for the job. Sometimes four languages is better than one. Sometimes not. Knowing which to pick separates you from the code monkeys.

So where did this come from?

This wasn't inspired by a post on Daniel Glazman's blog was it?

Free?

Free for any purpose eh? This will go well for the interface to my baby mulching machine.

Better question

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?

Re:Better question

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

Great example of hard-coding reducing size.

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!).

Main Difference

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.

Browser support

I love CSS and use it at every opportunity, but everyone is probably aware that the big CSS headache is browswer compatibility for features like positioning, and so forth. The worst offendor of modern browsers seems to be IE for Mac; why it is even worse than normal IE, I don't know, but it seems to be.

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....

XML/XHTML as a layout language?

As the old saying goes ... those who do not understand TeX are doomed to continually re-invent it ... badly.

Re:XML/XHTML as a layout language?

I write my papers in TeX, mainly because it's so easy to create equations. In general though, as a layout language to produce documents that look just how I want, it's a fucking nightmare.

Riiightt

The article boils down to: XSL (FO) is harder to use than CSS, so CSS r0xx0r5!

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 [microsoft.com]. 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."

XSL isn't trying to replace CSS

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

aren't XUL and firefox good examples?

XML + CSS?

There is no way I am even attempting to RTFA...

I mean /. topics usually contain several links, but that is just link overload...

The authors aren't talking about using browser-CSS

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 [yeslogic.com], (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.

Nerd fight!!!

an article titled Printing XML: Why CSS Is Better than XSL [xml.com] 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! [walsh.name]".

Let the hair pulling and the name calling begin.

Program vs. XSLT

I have looked at XSLT code and its pretty horrible.
Its much easier to write a Perl script to read in the XML, "transform" it and write out new XML.

css is better, but is still full problems

i love css, it has made my life much easier. yet it still has been the cause of many nights of frustration. centering blocks, floating images appearing sparadically, poor.. yes i say poor documentation! bad browser support, etc. css is much better than xsl but we still need something more universal and sensible.

Why use either?

If a program uses XML to store something that is meant to be printed, use that program. For example, I use AbiWord to print AbiWord documents, which are XML. Whatever AbiWord uses to convert the XML so the printer can understand it is not something I care about unless I am an AbiWord developer.

Whatever works best to print XML that represents foo is irrelevant if foo wasn't designed to be printed.

Note to IT community...

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.

It's apparently already slashdotted.

The second link in the story (for the 1000-line XSL stylesheet) seems to be slashdotted already. The best part is that when I tried to go there, I got

XML parsing error

In nice, big text. Way to hold the the XSL fort, guys!

Jeremy

DOH!!!!

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.

WFT???

Doesn't XSL convert XML to HTML (or any other document) anyway?

In my world I use both. XSL when I need something really robust; CSS when I need to reuse css styles.

Both have their place. Arguing whether one or the other is better is really moot. You can use CSS with XSL to render XML anyway.

As a matter of practicality...

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.

XSLT is for transformation

As an XSLT developer, I agree that CSS is simpler and more readable. However: the "T" in XSLT stands for "transformation". It means that you can do things like generating a table of contents, a table of figures, etc. which would not be possible with just CSS.

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.

Please...

Everyone knows print technology peaked with troff.

xsl:fo-nonsense

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...

Size.

Is it the size that matters, or how you use it?

XSL is not XSL-FO

Everyone seems to be confusing XSL-FO (formatting objects) with regular XSL (what used to be called XSL-T). Formatting objects are admittedly more complicated than CSS. But "regular" XSL, which transforms XML to XML, (X)HTML, or even text, is incredibly useful, flexible, and fun! The work I do takes XML files, transforms them using XSL into XHTML, and then formats that with CSS. Simple!

Proof that CSS is better than XSL

http://zengarden.20megsfree.com/ [20megsfree.com]

COBOL better than XML

Vastly. XML is just a solution looking for a problem. XML without user agreements is so useless. You could achieve the same results, with the same effort using COBOL file discriptions.

Don't people use both in ther same application?

As a developer, I have used XSLT in combination with CSS, so that you have the best of both worlds. XSLT doing transformations and spitting out CSS classes based on the XML document and its criteria. I didn't think they were mutually exclusive, but more like they compliment each other.

Beware of the things you say

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 :-).

I got a better one

Your 20,000 line Java code can be replaced by my one line C code... beat that! Clearly one line doing the same thing as 20,000 lines means C is superior...

I mean, sheesh... line counts make things better? pleeeze...

we also find out why...

Apache/1.3.9 (Unix) Debian/GNU PHP/4.0.3pl1 mod_ssl/2.4.10 OpenSSL/0.9.4
thru Catchcom

is better than

Apache/1.3.33 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.4 PHP/4.3.10-2 mod_ssl/2.8.22 OpenSSL/0.9.7d
thru Charter Communications

never say never

This is just another example that the best way to get proven wrong is to claim that something is impossible or to claim that language X can NEVER do Y.
We see this time and again.

What Slashdot needs

You know what /. needs?

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.