Slashdot Log In
Printing XML: Why CSS Is Better than XSL
Posted by
michael
on Thu Jan 20, 2005 10:45 AM
from the anything-you-can-do-i-can-do-better dept.
from the anything-you-can-do-i-can-do-better dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Tru Dat (Score:5, Insightful)
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 (Score:3, Insightful)
How do you propose they do that? Imposing fines? What can they do besides endorse something?
Re:Tru Dat (Score:3, Funny)
Step 1: Purchase the bullwhip.
Step 2: Firmly grasp bullwhip
Step 3: Purchase a ticket to Redmond, Wa
Step 4: Start swinging!
Re:Tru Dat (Score:2)
I think the parent proposed enforcement via something involving a whip and bare asses.
That's a start. Maybe something involving goats as the next step...
Re:Tru Dat (Score:4, Funny)
Oh, did I just make a silly comment? Sorry... (again)
Parent
Re:Tru Dat (Score:3, Funny)
Re:Tru Dat (Score:3, Informative)
Re:Tru Dat (Score:4, Insightful)
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.
Parent
Re:Tru Dat (Score:3, Interesting)
Is it like SVG where there is/was no single 100% compliant renderer, yet the w3c had something magical to make their few sample screenshots?
Re:Tru Dat (Score:4, Interesting)
Parent
SVG (Score:3, Informative)
Re:SVG (Score:3, Informative)
Re:Tru Dat (Score:4, Informative)
Parent
Re:Tru Dat (Score:5, Insightful)
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.
Parent
Re:Tru Dat (Score:3, Interesting)
So while both have their uses, CSS in combination with Javascript (or any scripting language for that matter) has far more functionality and flexibility.
In presenting documents with a web browser, yes, I agree. But traditionally, XSL was a server side headless operation for producing print quality documents.
Where is the commandline CSS and javascript engin
Re:Tru Dat (Score:4, Insightful)
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.
Parent
Free? (Score:2, Funny)
Better question (Score:2, Insightful)
Re:Better question (Score:4, Informative)
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
Parent
Re:TeX (Score:3, Interesting)
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!
Troll? (Score:3, Insightful)
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
Great example of hard-coding reducing size. (Score:5, Interesting)
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!).
Correction - not text sizes, but paper sizes (Score:2)
Re:Great example of hard-coding reducing size. (Score:3, Insightful)
I hate XSL and whenever possible use an actual programming language.
Main Difference (Score:5, Insightful)
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 (Score:3, Insightful)
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....
Yes it does (Score:2)
Something like the XSL:FO described I would say would be more genera
Re:Browser support (Score:2)
A little, though it hasn't been as bad in my experience. But the beauty of XSL is you can transform it at the server end.
I don't see why people act like you have to use one or the other, In my experience, its best to compliment eachother;
Data goes in XML.
XSL transforms XML data into XHTML for formatting(stripping out al
XML/XHTML as a layout language? (Score:5, Insightful)
Re:XML/XHTML as a layout language? (Score:2)
Anyhow XML/XHTML has a somewhat different purpose/market. The purpose is not to create a perfect typeset document but a template that can be used for any given XML document that fits the genre. You could do this to some degree with TeX and it's references (it's been a loooong time), but I think these systems do it better.
Re:XML/XHTML as a layout language? (Score:5, Insightful)
Parent
WYSIWYG Quark XPress?!? (Score:3, Interesting)
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 Y
Re:XML/XHTML as a layout language? (Score:3, Interesting)
Well, except for the fact that TeX is about three million years behind the state of the art in typography.
And if you think QuarkXPress is worth using, no offense, but you're about three million years behind the state of the art, too. It's InDesign or nothing today.
You do realize that InDesign's typesetting engine is based on TeX, don't you?
Ahh, the delicious irony.
Re:InDesign / TeX (Score:3, Interesting)
The main component in URW's HZ that is borrowed from TeX is the paragraph layout algorithm (partly because Knuth's is good and more or less freely available). Adobe licensed HZ mainly for the microtypography extensions (optical scaling), for its better hyphenation and for its kerning. In these respects, HZ is not on
Riiightt (Score:4, Insightful)
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 (Score:2, Insightful)
aren't XUL and firefox good examples? (Score:2)
XML + CSS?
The authors aren't talking about using browser-CSS (Score:5, Informative)
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!!! (Score:3, Funny)
Let the hair pulling and the name calling begin.
Note to IT community... (Score:4, Insightful)
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... (Score:3, Insightful)
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
It's apparently already slashdotted. (Score:4, Funny)
In nice, big text. Way to hold the the XSL fort, guys!
Jeremy
DOH!!!! (Score:3, Informative)
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.
As a matter of practicality... (Score:4, Insightful)
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 (Score:5, Informative)
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.
xsl:fo-nonsense (Score:4, Informative)
Proof that CSS is better than XSL (Score:3, Funny)
What Slashdot needs (Score:3, Funny)
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.
Incorrect comparison (Score:5, Interesting)
Re:CSS itself is overused (Score:3, Insightful)
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.