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.

how about XSL **AND** CSS

I didn't read the article yet but I just got through my first experience with XSL. I used XSL to turn XML into HTML and used CSS to format that HTML.

http://greggman.com/headlines/2005/2005-01-16-xslt -rss.htm [greggman.com]

Why is there an argument?

Herd mentality

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

Proffesionals are funny people.

Now I'm not one of them, and don't know if I'll ever be, but it's rather odd that they're comparing apples to oranges again. Repeat after me, every task can be accomplished with the appropriate tool. CSS is for Style (in case you forget), what's the point of having it do anything else. XSL (I never used it, so you'd know) FTFA XSL contains loops, conditionals, etc... Hmm... a tool for a DIFFERENT job perhaps? The only things that dissapear are things without purpose. Clearly, that is NOT the case.

Incorrect comparison

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.

Last name is Lie...

and I'm supposed to beleive what he says?

But what I really Need . . .

What I really need is a programmer who understands the binary language of XSL . . .

. . . XSL?! Sir, my first job was programming XML, very similar to your XSL in most respects.

Do you program Perl?

Of course I do, sir, I must type some for you.

Alright, shut up. --He'll do. Luke! Take these two programmers and get them cleaned up.

use XQuery for transformations

To handle transformations (as a separate issue from styling) the new XQuery [w3.org] language has some advantages over XSLT. The syntax is a lot more readable and more concise, and it's actually a reasonable programming language. It's a superset of XPath, which may people (including XSLT users) are familiar with. On the other hand, it doesn't have XSLT's "template processing" model, which simplifies writing transformations, and it's not a finished standard yet (though it's close). My article [gnu.org] discusses and illustrates using XQuery to transform XML for presentations. It's about generating web pages, while the parent is about generating PDF, but it does suggest it might be worth trying XQuery for generating XSL-FO (or even XHTML+CSS).

Article is about printing XHTML, not XML

Printing XML will require you to first convert XML (in some arbitary format) to (X)HTML - this is something CSS cannot do.

You need XSL to convert XML to HTML/PDF or any other format for printing.

News just in Chalk is better than Cheese...

First off *slaps the story poster* call it XSL-FO, not XSL which tends to infer XSLT which is perfectly good and often used in combination with CSS.

Now *slaps the person who wrote the post*, if youre not going to write a fair comparison don't bother writing one at all, the XSL-FO shows a page-size selector which will work for any size page, and he compares this to a one-size A4 CSS definition, I stoped reading at that point, if your going to argue Hello World is better than A cellular automota because it's got less lines of code in it, I don't want to hear any more of your arguments.

Line count comparison

Diverging more generally to the topic of XML...

I'm not sure it's fair to compare a 100 line straight text file to a 1000 line XML file and say that one is inherently superior. Having worked with XML, crafting it by hand, running in to all sorts of parsing errors, I've come to one conclusion:

XML was never built to be written by hand, or to be read with the human eye.

After all, these are text files, and it's not like we're using systems with only a few hundred kilobytes of storage anymore. I can see a distinct advantage to enforcing a schema on data, even if it is a total pain in the ass to enforce it.

I can craft 100-200 line XML files in the manner that we all craft HTML by hand, and my patience *just* holds out through all the parsing errors.

What we do need is a good (ideally open source) XML editor that's as natural and intuitive to use as Notepad (or more ideally Textpad) is to edit text files.

I haven't seen one yet. I keep going back to really good text editors and using my brain and lots of iterations checking that the XML matches the schema to keep me from going insane.

Some of them are out there, but they're all so *fiddly*. Fiddly enough to scare off a data content author, who isn't a programmer. Given a schema, editing XML should be Microsoft Word easy (sans Clippy). I've not seen it there yet.

Then again I'm an old bastard (30) who wants to edit everything by hand no matter what. It's hard to break that habit.

CSS still lacks a great deal

CSS may be better than XSL, but it still can't render fonts as well as book printing technology practiced 500 years ago. The whole question of rendering fonts and default fonts needs to be resolved.

Strange comparison

Everyone I know doing CSS uses it client side. Everyone I know using XSL uses it server side. Often both are used at the same time, with XSL used to transform the XML into XHTML, and the CSS used for pretty presentation.

I'd rather see it compared to other templating solutions. It seems to me that XSL is like a functional language compared to other templating engines acting more like an imperative language (I said like, it's not a great analogy). It would appear to me to be a bitch to render XSL pages real-time if, as I see in many tutorials, the transforms are an extensive list of recursive <xsl:apply-templates>. How fast are the XSLT parsers these days?

Phillip.

Why CSS is better than XSL

because it does something completely different?

Re:ATTENTION!

Taco ignores all emails about his beloved $20K-a-year staff

Is that all they make? References? Really, it's not worth getting out of bed for that.

Re:There is Nothing Worse Than XSL

A lit match?

Re:what do we have here...

Hey, step off Prince! He's a fellow Minnesotan... Yea, sure ya betcha!!!

Besides, I just saw him at the Golden Globes this past Sunday. Okay, so he looked like a re-animated corpse from the 80s, but he was there nonetheless!

Re:PDF is the only way to print *properly*

RTFA. Carefully.

Re:CSS itself is overused

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.

Re:CSS itself is overused

I think you need to see this: http://developers.slashdot.org/comments.pl?sid=136 703&cid=11420540
(don't forget to read the text, you might want to choose a different design :) )

and try to reevaluate your opinion of CSS in general, and expand it to all the things that work in all browsers and not just text formatting. (CSS1?)

Re:Call me stupid....wait....

No, but I could show you how to make a nice MLT!

no no no.

Get with the program... you goal would be better served with standing behind standards based development and yet you preach embedding presentation with content.

" I've lowered my tollerance for bad HTML and shoehorning designs into CSS."

This comment alone shows how out of touch you are with modern CSS based development...

Check out the zengarden, the CSS vault and CSS beauty for a lesson.

Re:CSS != XSL

The article compares how two different languages describe the same task (namely, formatting a W3C document). I thint that's a reasonable basis for comparison even if the languages have different scopes (as the XML.com article also notes).

Re:what do we have here...

Go see a Prince concert. The man is still amazing.

Re:There is Nothing Worse Than XSL

Awww... Looks like someone tried to learn XSL and couldn't get their head around it, then decided to call it garbage rather than admit to themselves that they're simply not smart enough to understand it.

Re:CSS itself is overused

(What idiot labeled this "troll"? I find it carefully reasoned, even though I disagree with much of what it says.)

Until the browsers converge on CSS, (which is great in theory) please use nested tables for your layouts. They work great all the way back to Netscape 4, which is all you can ask for these days.

No they don't. Pages formatted that way depend on a minimum screen resolution. And they don't comply with accesibility standards. Tables should be used for tabular data, period.

I agree that there's a convergence problem with browser support of CSS. But the intersection of CSS support you see on all the current browsers is enough for most purposes. That still leaves your legacy users in the lurch. But if legacy support is that important to your web site, it makes more sense to scale back the fancy formatting, instead of using obsolete kludges.