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

Comments

Tru Dat

[Foofoobar]

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

[mmkkbb]

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.

How do you propose they do that? Imposing fines? What can they do besides endorse something?

Re:Tru Dat

[rjstanford]

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

[dubious9]

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

[dubious9]

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.

Re:Tru Dat

[TheViciousOverWind]

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.

Everytime I read this I think "Bullshit"... This might work when you're just hobby-programming, but real projects in real workplaces are mostly done in ONE language... I don't do half my app in Ruby when the rest is in PHP because it would be faster/easier/more fun. I stick to PHP because that way there's consistency, and if I decide to go find a new job, the person taking over for me will still be able to read the source.

Better question

[Pan T. Hose]

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?

Main Difference

[rjstanford]

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

[revividus]

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?

[gowen]

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?

[mithras the prophet]

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

[Safety Cap]

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

Re:Riiightt

[DrVomact]

Yes, but this has nothing to do with XSL vs. CSS, it's about HTML vs. PDF. And yes, if control is what you're after, then PDF is the way to go. How dare a mere user set his browser's font size larger just because his eyes aren't so good anymore and he'd rather see big print? (Sure, I can magnify PDF, but that doesn't reflow the document, and I'm left scrolling all over the place to get to see the whole thing, sort of like a fly crawling over a giant newspaper page.)

There may be a good reason for your desire to control...but I sure hope it isn't just a desire to dictate how your documents look in my browser.

Q: How can you tell if a website was designed by a know-nothing monkey? A: "This site best viewed in 800x600, 1024x768, etc."

How about: A: It loads in Acrobat.

XSL isn't trying to replace CSS

[Anonymous Coward]

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

Note to IT community...

[kahei]

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.

Re:Note to IT community...

[Doctor Crumb]

"Also please stop using XML to represent arbitrary data. It's a markup language."

I find XML quite good at representing arbitrary data, and at the same time quite bad as a markup language. It's terrible at being a programming language though; it has all the readability of assembler and all the power of BASIC. My preferred dataflow is (input)->(a real language)->(XML/XSLT)->((HTML + CSS)|LaTeX). Each part has its strengths, and you'll have real issues if you try to get any one of these hammers to do everything.

As a matter of practicality...

[slcdb]

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.

Re:Great example of hard-coding reducing size.

[killjoe]

I would like to see a comparison to a "real" language like java or python or ruby or something.

I hate XSL and whenever possible use an actual programming language.

Re:CSS itself is overused

[russx2]

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.

Herd mentality

[lux55]

Why am I seeing so many bad reactions on here? Responses like "show me the browser support"? You don't need browser support for print! You need another program capable of it. So what that the first one to do it is commercial -- commercial businesses quite often outpace open source, truth be told.

Show me the browser support for XSL? The article is displaying an example of why CSS3 will solve most of the same problems 1000x more elegantly. XSL is Perl's (I like Perl, I don't like XSL) ugly kid brother -- got beat twice as hard with the ugly stick.

When XSL came out, where was the tool support for it? Nonexistant. Because it was just a standard first. The tool support even now, years later, is only partial.

So yes, CSS3 will take time to implement in the real world, but it's a clearly superior solution. Shortcomings? Probably more than a few. But if we WORK on them, we can overcome them, probably also 1000x more elegantly than the atrocity that is XSL.

So instead of bitching about someone getting it right for a change (now that we've wasted how many years trying to work with XSL), why not start up an open source project to build support for the new spec? This sounds like a good side-project for Mozilla.org or the KHTML folks (since they already have a rendering engine).

Troll?

[TheRaven64]

If this is a troll it's a very good one, since it reads like an honest question.

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.