Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Software

Printing XML: Why CSS Is Better than XSL 361

Posted by michael 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.

Printing XML: Why CSS Is Better than XSL More

Printing XML: Why CSS Is Better than XSL

Comments Filter:

  • Tru Dat (Score:5, Insightful)

    by Foofoobar ( 318279 ) on Thursday January 20, 2005 @10:48AM (#11419975)
    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 (Score:3, Insightful)

      by mmkkbb ( 816035 )
      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 (Score:3, Funny)

        by Foofoobar ( 318279 )
        How do I propose they do that? Easy.

        Step 1: Purchase the bullwhip.
        Step 2: Firmly grasp bullwhip
        Step 3: Purchase a ticket to Redmond, Wa
        Step 4: Start swinging!

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

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

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

        Put a Paypal link on the W3C site, so web standards buffs can donate to the cause of forming a private army for the W3C. Then, finally, this organization can have some enforcement power.

        That's really the only thing missing from the web-standards "revolution": Lots and lots of bloodshed.

        • Actually, if the W3 had a 50 million dollars prize for the first fully CSS1+2+3 compliant browser, people would fall over themselves to build the browser.

          • Actually, if the W3 had a 50 million dollars prize for the first fully CSS1+2+3 compliant browser, people would fall over themselves to build the browser.

            Well, yes, but I'd still rather my money went to a private army, pouring across the land, enforcing browser compliance and the separation of content from presentation.

            </hypocrisy. My own site uses table-based layouts>

    • Re:Tru Dat (Score:3, Informative)

      by procrastitron ( 841667 )
      IE isn't relevant to this topic actually. The article linked to is not about printing on the screen but actually printing to paper. They use CSS to produce a PDF document of the XML file, which can be printed as a book. The authors even say that they've already done this for their book Cascading Stylesheets, designing for the web

      • Re:Tru Dat (Score:4, Insightful)

        by rjstanford ( 69735 ) on Thursday January 20, 2005 @10:59AM (#11420114) Homepage Journal
        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 (Score:3, Interesting)

      by British ( 51765 )
      Are there any apps that fully support CSS to the last detail? I often see all too often "can't render CSS".

      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)

        by SenseiLeNoir ( 699164 ) on Thursday January 20, 2005 @11:18AM (#11420328)
        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.

        • SVG (Score:3, Informative)

          by British ( 51765 )
          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.

          • Re:SVG (Score:3, Informative)

            by SenseiLeNoir ( 699164 )
            Actually, the Sony Ericsson S700 (and i think the K700/K500, that is currenly all the rage here in UK) support not just static SVG, but also Animated SVG too (it comes with two sample animated SVG pics)

      • Re:Tru Dat (Score:4, Informative)

        by Vann_v2 ( 213760 ) on Thursday January 20, 2005 @11:20AM (#11420346) Homepage
        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.
        • That's because CSS3 is not a specification, it's a work in progress. If the drafts were to change tomorrow, and browsers supported the properties in a non-standard way, it would be more problematic than not supporting the properties at all - IE is proof enough of this. Browsers do support some parts of CSS3 - either by prefixing the properties with their vendor code (e.g. -moz-opacity) or by supporting properties of modules that are considered complete and unlikely to change.

    • Re:Tru Dat (Score:5, Insightful)

      by dubious9 ( 580994 ) * on Thursday January 20, 2005 @11:08AM (#11420225) Journal
      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.
      • Well you are talking about a combined tool which is highly arguable as being more efficient; is a combined function more efficient than two separate functions that work together? Some might say yes but the amount, in this sense, is negligible.

        And is it equally flexible? No. What if you only need to use CSS? The combined function set becomes overkill or bloat. And because you can combine CSS with any other scripting language out there, it can have a virtual unlimited amount of uses in comparison to XSL.

        So

        • Re:Tru Dat (Score:3, Interesting)

          by dubious9 ( 580994 ) *
          Caveat: I don't like XSL. It's too verbose and even simple logic steps tend to take a while to implement. I want a better solution. However...

          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
    • It says in the story that even IE supports a lot of this stuff... including page breaks and margins... I haven't tried it myself but it sounds promising!

      Friedmud

  • Free? (Score:2, Funny)

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

  • Better question (Score:2, Insightful)

    by Pan T. Hose ( 707794 )
    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 (Score:4, Informative)

      by tomstdenis ( 446163 ) <{moc.liamg} {ta} {sinedtsmot}> on Thursday January 20, 2005 @11:01AM (#11420136) Homepage
      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

      • TeX (Score:2)

        by bsd4me ( 759597 )

        6. Most TeX distros [like tetex] are FREE and open source.

        And there lot of OSS tools that support TeX. My favorite is using PARI/GP [u-bordeaux.fr] to do some math, and then using the TeX output to copy-and-paste into a document (like a journal submission). I did this for my last paper, and it worked well. The paper had to be submitted in Word format, though, so I made my editor re-enter all of the equations. :)

    • You are right that XML (and kin) are not typesetting systems.

      However, there is a language called XSL:FO [xml.com] (Formatting Objects) written on top of XSL that can be used to describe typsetting for XML documents, as printing is just one sort of transform. People usually use it to produce PDF's of data, but I have seen it used to produce a book of medical images.
      • I wrote a reporting system using XSL:FO. I had to later port it to LaTeX because XSL:FO is too immature. Due to design XSL:FO transformers eat memory for multiple page tables. TeX is designed very efficiently (it had to be back when originally written). The TeX based system is soooo much faster and more reliable!

        Joe
    • ... is TeX or Postscript better for storing more-or-less arbitrary data in an easy-to-parse format? Because that's the real point of XML. The advantage of something like XML:FO is that you can then take this nicely formatted data and convert it directly into something printable.

      And before you say it, no, there's no point converting to TeX or something else... if you're going that far, you might as well go straight to PDF, which is what XML:FO facilitates.
    • Is XML with CSS better than TeX, or Postscript for that matter?

      One of the first XSLs that I built converted NITF (the Newspaper Industry's XML Format) into TeX.

      Here's one thing that CSS can't do. Make something clickable. Few browsers support the :before and :after tags, which are required to do this.

      So CSS can format a static document, but XSL is required to make it interactive.

    • Troll? (Score:3, Insightful)

      by TheRaven64 ( 641858 )
      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

  • Great example of hard-coding reducing size. (Score:5, Interesting)

    by SuperKendall ( 25149 ) * on Thursday January 20, 2005 @10:54AM (#11420039)
    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 (Score:5, Insightful)

    by rjstanford ( 69735 ) on Thursday January 20, 2005 @10:54AM (#11420041) Homepage Journal
    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 (Score:3, Insightful)

    by revividus ( 643168 ) <phil@crissman.gmail@com> on Thursday January 20, 2005 @10:54AM (#11420044) Homepage
    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....

    • I've done a lot of stuff with XSL in the past, and know from experience that XSL does soffer some pretty annoying cross-browser unpleasnantness. That's why generally XSL is done on the server before the user sees it, though technically you could send the user an XML document and point them at a XSL file for transform. If you do anything tricky different browsers can break (even between different versions of IE, but then what else is new?)

      Something like the XSL:FO described I would say would be more genera
    • "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."

      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
      • This is the only worthwhile way to do it (and your output doesn't need to be XHTML+CSS, it could be HTML+CSS or even just HTML), because CSS 1+2, especially as currently implemented, is totally broken. You have to add non-semantic hooks (divs and spans) to your markup for pretty much any non-trivial layout. Non-semantic markup is dumb, because it breaks the whole point of semantic markup. If you want semantic markup, store your documents as pure XML and treat XHTML/HTML has a rich text/formatting language u
    • Does XSL suffer the same cross-browser incompatibilities?

      Yes and No. Certain browsers are missing support for Exslt's extensions for example, however, you can apply the XSL on the server side and serve the result, something you can't do in CSS. You can even use XSLT to create a PDF! Something you can't do in CSS.

      libxslt is very fast. Every page we serve is transformed before it is served, and we've survived multiple slashdottings just fine.

  • XML/XHTML as a layout language? (Score:5, Insightful)

    by gowen ( 141411 ) <gwowen@gmail.com> on Thursday January 20, 2005 @10:55AM (#11420048) Homepage Journal
    As the old saying goes ... those who do not understand TeX are doomed to continually re-invent it ... badly.
    • It's not very well known outside of academia. The only time I ever felt like TeX was better than all others was for highly mathematical school papers.

      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)

      by mithras the prophet ( 579978 ) on Thursday January 20, 2005 @11:13AM (#11420277) Homepage Journal
      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.
    • TeX is a fantastic solution ... if you want your documents to look like TeX documents.

      If you want something else, TeX is a hideous bitch-goddess from hell who wants to fuck you up the ass and then gnaw your head off.
      • Oh well, there go my mods.

        I submit that if one understands TeX (and LaTeX) and works with them as they are intended to be adjusted, that there's really no limit to what one can do, or what one can make things look like.

        In support of this, I offer the TeX Showcase at http://www.tug.org/texshowcase.

        (ob. discl. it includes some stuff from my personal portfolio at http://members.aol.com/willadams)

        Even bad typography can be mimicked as is shown in a (thankfully unreleased) package to mimic Word's typography

  • Riiightt (Score:4, Insightful)

    by Safety Cap ( 253500 ) on Thursday January 20, 2005 @10:57AM (#11420088) Homepage Journal
    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."


    • At the end of the article, the authors say this:

      By combining the print- specific CSS stylesheet described above with the WebArch document, a nicely formatted PDF document can be created.

      The point is that both CSS and XSL can be used to output to PDF. The authors state that CSS wasn't made to be a Turing-complete language, rather a layout language. They aren't saying CSS can do everything XSL can, rather that most of what you can layout with XSL can be replicated in fewer lines, and more readably, with CSS.

    • The thing that people tend to forget is that the web is about amatuers. That's why it took off. Anyone could write html, write their own website, and they did. Preserving that situation is a good thing.

    • Re:Riiightt (Score:2, Interesting)

      by biggles2k ( 559598 )

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

      Actually, the article boils down to: CSS is easier to use by those who must lay out both the electronic and printed page, so CSS r0xx0r5.

      This is very true since those who spend time designing and laying out readable pages are generally NOT programmers and may not have the desire or aptitude to decipher/code hundreds of lines of XSL prose.

      Basically, it's a matter of using the right tool for the right job. The article f

  • XSL isn't trying to replace CSS (Score:2, Insightful)

    by 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

  • The authors aren't talking about using browser-CSS (Score:5, Informative)

    by watanabe ( 27967 ) on Thursday January 20, 2005 @11:10AM (#11420239)
    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!!! (Score:3, Funny)

    by revery ( 456516 ) <charles@ca c 2 . net> on Thursday January 20, 2005 @11:11AM (#11420249) Homepage
    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.

  • 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.
    • I have been writing XSLT for some time and I'm under the same impression. Though the functional language is cool, I don't think the idea of making it XML was very good.

      Wouldn't it be simpler and better to design XSLT as a API, and transform XML using existing programming languages? Any XSL gurus have anything insightful to say about?
    • I agree. If I have to do anything other then a simple transform I would much rather do it in a language then XSL.
    • Its much easier to write a Perl script

      I wholeheartedly agree, but it probably depends on your mindset. I'd say processing/transforming XML with Perl is just as powerful as using XSLT and quite a bit more flexible, as Perl is quite forgiving. XSLT looks rigid and inflexible. Perl strives to make the easy tasks simple to accomplish and difficult tasks possible. I suppose XSLT makes all things possible, but no task completely simple. It looks to me to be about as fun to code in XSLT as it is to code in
  • 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.

  • 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... (Score:4, Insightful)

    by kahei ( 466208 ) on Thursday January 20, 2005 @11:15AM (#11420301) Homepage

    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.

    • God where are my mod points when I need them.
    • "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

  • It's apparently already slashdotted. (Score:4, Funny)

    by jemfinch ( 94833 ) on Thursday January 20, 2005 @11:17AM (#11420314) Homepage
    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
    • Comes up fine for me. That sounds like your browser kacking on the XSL, trying to parse it -- which makes sense, because you'd really run the XSL server-side and output a PDF or something (as SuperKendall pointed out), and your browser wouldn't normally even see this. So this may just be a case of user confusion.

  • DOH!!!! (Score:3, Informative)

    by Spy der Mann ( 805235 ) <spydermann DOT slashdot AT gmail DOT com> on Thursday January 20, 2005 @11:18AM (#11420326) Homepage Journal
    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.
    • XSL has two parts: transformations (XSLT) and formatting objects (XSL-FO). XSLT by itself is not meant for formatting, but XSLT and XSL-FO together are meant for exactly that.

      I suspect that most of the compactness of the CSS solution is that CSS has built-in knowledge of HTML. The XSLT stylesheet will have to implement that from scratch. So CSS may be a win if you are using XHTML, but less so if you are using your own XML vocabulary. In the latter case, a common approach is to have an XSLT stylesheet th
  • 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... (Score:4, Insightful)

    by slcdb ( 317433 ) on Thursday January 20, 2005 @11:20AM (#11420348) Homepage
    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 (Score:5, Informative)

    by Pascal Sartoretti ( 454385 ) on Thursday January 20, 2005 @11:21AM (#11420360)
    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.

  • xsl:fo-nonsense (Score:4, Informative)

    by flibuste ( 523578 ) on Thursday January 20, 2005 @11:25AM (#11420403)
    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...
  • Comment removed based on user account deletion

  • Proof that CSS is better than XSL (Score:3, Funny)

    by Sowbug ( 16204 ) * on Thursday January 20, 2005 @11:33AM (#11420540) Homepage
    http://zengarden.20megsfree.com/ [20megsfree.com]
  • 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 :-).
  • 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...
  • 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

  • What Slashdot needs (Score:3, Funny)

    by digitalgiblet ( 530309 ) on Thursday January 20, 2005 @12:30PM (#11421289) Homepage Journal
    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.

  • Comment removed based on user account deletion

  • Incorrect comparison (Score:5, Interesting)

    by Carewolf ( 581105 ) on Thursday January 20, 2005 @01:00PM (#11421679) Homepage
    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.

Slashdot Top Deals

The fancy is indeed no other than a mode of memory emancipated from the order of space and time. -- Samuel Taylor Coleridge

Close